Network Access Control Implementation at AU

1. Network Access Control through Quarantine, Remediation, and Verification– May 5th, 2008

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

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

4. Agenda • About AU’s NAC implementation • Facts • Origins/Justification • Timeline • Results • Challenges and lessons learned • Technical challenges • Organizational/Cultural challenges • Conclusion • Top Five Takeaways about NAC in the University environment

5. Facts • AU uses “Cisco NAC Appliance” • Formerly Cisco Clean Access • Formerly Perfigo • Average ~4000 devices • 10 production servers/managers (failover pairs) • 4 test servers (failover pairs) • 1.5 FTE for administration

6. Origins of NAC at AU • Prior to NAC • Mac Address Registration System (MARS) • Simple Device Registration • Education about best practices, no enforcement • Developed in house • No longer effective enough • Fall 2004 • 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 • InfoSec staff learned of new technologies at conferences

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

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

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

10. Lessons Learned:Technical (continued) • Keep your requirements simple • 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 • By the end of the semester AU has 2000+ • Game consoles, printers, voip phones,other devices • Scheduled cleanup • Defined processes + data elements • No involvement of security personnel is ideal

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

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

13. Lessons Learned: Organizational/Cultural (continued) • Find Partners across campus • 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

14. My top five lessons learned: • Risk • Resources • Communication • Management buy-in • Metrics are essential

15. Questions?