Network Access Control through Quarantine Remediation and Verification

Network Access Control through Quarantine, Remediation, and Verification – May 5 th, 2008 Eric Weakland - Information Technology - American University -eric@american. edu 1

About Me n Welcome to Arlington! n Director, Information Security - Office of Information Technology n Have held a host of roles at the university u Help Desk Manager u PC Support Technician u Router/Network Administrator u Server Administrator u Software Analyst (network application deployment) u Information Security n Masters in IT management n CISSP, CNE n Staff of 3 Information Security Engineers n Report to the CISO n Without them, I could not be here speaking to you. Eric Weakland - Information Technology - American University -eric@american. edu 2

About AU n Located in Northwest DC n Founded 1883 n 4 year, Private, not for profit University n 11000 students n 3000 faculty/staff n 3400 "pillows” n Approximately 6500 network devices n Ubiquitous wireless system n Central IT and pockets of Local Service Providers n The Eagles made the first ever NCAA tournament this year! Eric Weakland - Information Technology - American University -eric@american. edu 3

Agenda n n n About AU’s NAC implementation u Facts u Origins/Justification u Timeline u Results Challenges and lessons learned u Technical challenges u Organizational/Cultural challenges Conclusion u Top Five Takeaways about NAC in the University environment Eric Weakland - Information Technology - American University -eric@american. edu 4

Facts n AU uses “Cisco NAC Appliance” u Formerly Cisco Clean Access u Formerly Perfigo n Average ~4000 devices n 10 production servers/managers (failover pairs) n 4 test servers (failover pairs) n 1. 5 FTE for administration Eric Weakland - Information Technology - American University -eric@american. edu 5

Origins of NAC at AU n n Prior to NAC u Mac Address Registration System (MARS) u Simple Device Registration u Education about best practices, no enforcement u Developed in house u No longer effective enough Fall 2004 u u Era of Sasser, Blaster, Slammer — Infections took down network during finals week. — Mostly student computers New CIO — Mandated that the risk posed by mis-configured computers needed to be mitigated. (Jan, 05) — Authorized the requirement of a client on student computers — Info. Sec staff learned of new technologies at conferences Eric Weakland - Information Technology - American University -eric@american. edu 6

Implementation Timeline n Product Research/Requirements Development - Jan-April, 2005 n Product Selection - April, 2005. n Requirements Selection - May, 2005 n Internal (OIT) Pilot - May, 2005 n Student Implementation - June-August, 2005 n Policy Adoption - Dec. 2006 n Faculty/Staff Pilot - Jan - March, 2007 n Faculty/Staff Rollout - April - August, 2007 n Faculty “Audit and Remediation” - September, 2007 - April, 2008 n Requirements enforced for entire community - April 29 th, 2008 n Hoooray! Eric Weakland - Information Technology - American University -eric@american. edu 7

Results n 80% reduction in malware tickets n Better processes/policies to control access n Better methods to locate problem clients n Problems tied to users not hardware n Role based access n Metrics that we gather give us a lot more insight into how our network is used (not supplied by vendor, addons are available now) u OS u Time profile u What are users failing on? u Etc. Eric Weakland - Information Technology - American University -eric@american. edu 8

Lessons Learned: Technical n n NAC has real risks, make sure you understand them u Network outages/Availability u Another point of failure u Inband vs out of band, neither is foolproof u Troubleshooting can be harder u Upgrades often mean outages u Monitoring is essential Test test u n Product support lifecycle u n Full test network A vendor may not support product X by the time it goes gold. NAC isn't security u Just because a computer meets your standard, doesn’t mean it is “secure, ” just “more secure” u It is a technical component of a security program u An arrow in the quiver u Can verify settings and enforce policy — Not auto software distribution (endpoint management) Eric Weakland - Information Technology - American University -eric@american. edu 9

Lessons Learned: Technical (continued) n Keep your requirements simple u n AU’s Requirements seek to put the computer on “autopilot” — Member of the community (authentication) — (XP)Antivirus — Antispyware — Firewall — Microsoft Update - set to “on” and “install automatically” — Software versions (Firefox) — Certain clients need handholding for even simple requirements Exception management u By the end of the semester AU has 2000+ u Game consoles, printers, voip phones, other devices u Scheduled cleanup u Defined processes + data elements u No involvement of security personnel is ideal Eric Weakland - Information Technology - American University -eric@american. edu 10

Lessons Learned: Organizational/Cultural n n Involve a Management Champion early, and give them what they need! u AU’s implementation was delayed much in part to management changes at AU u Relevant policy may need to be drafted or amended u Management can help make it an University goal, not an IT goal! u Study your organizational chart u Be prepared to supply metrics to management u Research and understand the business goals of your customers u Keep management well briefed in case there are problems u PLUS: This a great opportunity to network with customers from across the organization! Make sure management understands the impact/cost u Potentially Increased availability risk u Need for dedicated “test” infrastructure u High requirements for documentation, maintenance, testing, change control etc. u Lots of staff time/potentially more staff u DANGER: “Do I really want to know? ” (because then you have to fix it!) Eric Weakland - Information Technology - American University -eric@american. edu 11

Lessons Learned: Organizational/Cultural (continued) n Implementing NAC needs a lot of communication n Pre and post communication u Start early u Encourage Students to prep their computers before coming to campus, repeatedly u Better if communication from management for staff/faculty, not IT u Provost/Deans/Department heads u Give management statistics about what you find in their environment n Dispelling myths and rumors - faq's, blogs, status pages n The "blame nac" syndrome n "guest/visitor access" n u ”Hotelers" u Summer programs u Libraries u Sporting events u Conferences Hard to manage users Eric Weakland - Information Technology - American University -eric@american. edu 12

Lessons Learned: Organizational/Cultural (continued) n Find Partners across campus u u Pilot departments — Get your “special attention” while you refine your processes — Can help as references for reluctant departments — Look for departments with risky information - they have a vested interest — Look for departments with “squeaky wheels” IT partners — Networking Group — Help Desk/Communications group — Desktop Support group Eric Weakland - Information Technology - American University -eric@american. edu 13

My top five lessons learned: n Risk n Resources n Communication n Management buy-in n Metrics are essential Eric Weakland - Information Technology - American University -eric@american. edu 14

Questions? Eric Weakland - Information Technology - American University -eric@american. edu 15