Developing an Effective & Affordable Security Infrastructure in a Small College Environment
About   Penn College Williamsport Technical Institute, founded 1941 Williamsport Area Community College, founded 1965 Pennsylvania College of Technology, founded 1989 Special Mission Affiliate of Penn State University Accredited - Middle States Association of Colleges and Secondary Schools  6,358 headcount - 5,891 FTE 288 FTE faculty, 518 FTE staff B.S., A.S. and certificate degrees in over 100 majors Specialize in vocational and technology-based education Strong focus on small class sizes and hands-on instruction www.pct.edu
Williamsport, PA
IT   Infrastructure 2,600 College-owned computers, 1,400 student-owned computers in residential complexes 1,600 computers in 50+ academic computer labs, student to computer ratio of 4:1 Standard computer lab software includes Microsoft Windows XP, Office 2003, NetMail POP3 e-mail system
IT   Infrastructure (cont’d) 1,000 staff/faculty PCs Standard employee image: Windows XP, Office 2003, Novell GroupWise, iSeries client Novell Directory Services (NDS) IBM iSeries mainframe, home-grown legacy administrative applications WebCT, Sirsi, eRecruiting, Raiser’s Edge, Cbord Odyssey, EBMS 25 Novell, 15 Microsoft, 3 Linux, 1 Sun, 1 AIX server
IT Infrastructure (cont’d) 100% Cisco network infrastructure except for Packeteer Packetshaper Fast Ethernet via CAT5 for all building LANs, Gigabit Ethernet via fiber for backbone Dual Cisco 6500s for redundant core Fractional T-3 (30 Mbps) Internet service Dial-up Internet access provided for employees, not students About 50% wireless coverage
Campus Network Layout
Information Technology Services Organization (50 employees) Desktop Computing Academic Computing Technical Support/Help Desk Technical Writer/Trainer Administrative Information Systems Network Applications Mail & Document Services Media Services Telecommunications
Post Y2K IT Security “Problem” Increasing threats from viruses, trojans, worms, hackers, etc. Lack of security standards No coordinated security response Poor security awareness Minimal security policy No security testing
The “Challenge” Limitations Budget Staff Time Large backlog of post Y2K projects Balancing security effectiveness with efficient resource management
Solution Analysis Dedicated security staff vs. security team Advantages of team approach: Utilizes existing staff and expertise Spreads/diffuses the importance of security across all functional IT areas Funded through existing budgets Disadvantages: No centralized focus/authority Long lead time to develop expertise Staff time directed away from other projects Not invented here syndrome
The “Solution” IT management recommended forming a campus “security team.” Each area of the IT department committed one employee and a percentage of its budget. A senior manager was designated to provide leadership and coordination of this team effort.  The team met weekly over an initial 18 month period, then bi-weekly. Rotating duty officer/CERT format
The Context Risk vs. investment Scope and impact for priority Mitigating risk factors Administrative data locked up in IBM iSeries (AS/400) GroupWise e-mail system Institutional policy requiring data files to be stored on network drives Centralized IT management and budget culture
7-Layer Security Approach Layer 1 - Physical Layer 2 - Internet Layer 3 - Network Layer 4 - ResNet Layer 5 - Servers Layer 6 - Employee PCs Layer 7 - Social
Layer 1 - Physical Before Distributed servers, not physically secured, some actually in staff/faculty offices Network components not secured Minimal UPS protection After Most non-academic servers moved to secured data center; backup generator Wiring closets secured UPS for all servers and network equipment
Layer 2 - Internet Before Internet router with public IP addresses No filtering of ports After Cisco PIX firewall with PAT translation initially, later acquired additional IPs, changed to NAT ( still occasional problems, need an XLATE clear ) Access control list on Internet router ( example ) Packeteer - Although purchased for bandwidth control, provides another layer of “protection” and “detection”
Internet Router ACL access-list 115 permit tcp any 0.0.0.0 255.255.255.0 established access-list 115 deny  ip 10.0.0.0 0.255.255.255 any access-list 115 deny  ip 127.0.0.0 0.255.255.255 any access-list 115 deny  ip 172.16.0.0 0.15.255.255 any access-list 115 deny  ip 192.168.0.0 0.0.255.255 any access-list 115 deny  ip 224.0.0.0 15.255.255.255 any access-list 115 deny  ip host 0.0.0.0 any access-list 115 deny  ip 12.23.198.0 0.0.0.255 any access-list 115 deny  ip 12.23.199.0 0.0.0.255 any access-list 115 deny  ip any 0.0.0.255 255.255.255.0 access-list 115 deny  tcp any any eq 135 access-list 115 deny  udp any any eq 135 access-list 115 deny  tcp any any eq 137 access-list 115 deny  udp any any eq netbios-ns access-list 115 deny  tcp any any eq 138 access-list 115 deny  udp any any eq netbios-dgm access-list 115 deny  tcp any any eq 139 access-list 115 deny  udp any any eq netbios-ss access-list 115 deny  tcp any any eq 445 access-list 115 deny  udp any any eq 445 access-list 115 deny  tcp any any eq 593 access-list 115 deny  udp any any eq 593 access-list 115 deny  tcp any any eq 3333 access-list 115 deny  udp any any eq 3333 access-list 115 deny  tcp any any eq 4444 access-list 115 deny  udp any any eq 4444 access-list 115 deny  tcp any any eq 69 access-list 115 deny  udp any any eq tftp access-list 115 deny  tcp any any eq 161 access-list 115 deny  udp any any eq snmp access-list 115 deny  tcp any any eq 162 access-list 115 deny  udp any any eq snmptrap access-list 115 deny  udp any any eq 1993 access-list 115 deny  tcp any any eq 1900 access-list 115 deny  udp any any eq 1900 access-list 115 deny  tcp any any eq 5000 access-list 115 deny  udp any any eq 5000 access-list 115 deny  udp any any eq 8998 access-list 115 permit icmp any any echo access-list 115 permit icmp any any echo-reply access-list 115 deny  ip any any log-input
Layer 3 – Network - Before 10.x.x.x organized geographically; each “building complex” has a subnet; 10.1.x.x, 10.2.x.x, 10.3.x.x, etc. Any to any routing philosophy Simple telnet to devices No central security scheme
Layer 3 – Network - After 100% VLAN scheme VLANs based on  computer/user role Internet style ACLs applied  on traffic leaving VLANs Traffic denied entering VLAN if no reason for the traffic Extended today to separate VLANS for point-of-sale stations, HVAC, wireless, dial-up; each with its own ACL SSH required to access devices, coordinated userid/password with Cisco ACS server that LDAPs to our NDS 10.1.x.x network equipment 10.2.x.x servers 10.3.x.x printers 10.4.x.x staff 10.100.x.x ResNet Etc.
Layer 4 – ResNet Before Normal network subnet No restrictions ISP attitude No scanning After – version 1 Single VLAN ACL limited access to other campus VLANs After – version 2 VLAN per 48 port switch Internet style ACL “rule set” to block known bad ports such as 445 Routine scanning and quarantining
Layer 5 – Servers - Before Public IP address via firewall conduit Distributed physically No port filtering Inconsistent patch strategy No virus protection Inconsistent HTTPS implementation Many outside of the “network” department No scanning for vulnerabilities No disaster recovery plan
Layer 5 – Servers - After Servers in data center or managed by server group HTTPS required for any sensitive data Private IP addresses mapped to public via “conduit” in the firewall Port filtered in the firewall, deny all, allow those required for specific services Port filtered coming out of ResNet and student computer labs Managed patch strategy, critical patches applied in 24 hours Symantec Anti-Virus on servers NetMail/CA eTrust anti-virus and RBL filtering for e-mail GWAVA/Symantec Anti-Virus e-mail filtering GWAVA attachment filtering Routine Nessus scanning Comprehensive disaster recovery plan
Layer 6 - Employee PCs After Private IP address via PAT/NAT Managed Symantec Anti-Virus “ Push” of critical Microsoft security patches via Novell ZenWorks Nessus scanning Before Public IP address No anti-virus No patch management No scanning
Layer 7 - Social Before Little or no public awareness No AUP Loose user ID and password policies “ It won’t happen here, we know everyone personally After Acceptable Use Policy  Accounts blocked after 3 failed log in attempts Passwords changed every 180 days Regular communication via online newspaper Security education classes
What’s on the radar screen? Spyware PC firewall Instant Messenging issues VPN Network access control Two factor authentication Security as it affects privacy issues E-mail security
Conclusion Security team was the right approach for us Effective, no significant down-time except for Blaster/Welcia, fall 2003 Cost-efficient Diffused security awareness across the department Developed security skills across ITS Security Infrastructure Cisco PIX firewall Packeteer Packetshaper Cisco VLANs/ACLs Symantec Anti-Virus Novell ZenWorks GWAVA Anti-virus/attachment filtering Nessus
Discussion
Slide to link

Developing an Effective

  • 1.
    Developing an Effective& Affordable Security Infrastructure in a Small College Environment
  • 2.
    About Penn College Williamsport Technical Institute, founded 1941 Williamsport Area Community College, founded 1965 Pennsylvania College of Technology, founded 1989 Special Mission Affiliate of Penn State University Accredited - Middle States Association of Colleges and Secondary Schools 6,358 headcount - 5,891 FTE 288 FTE faculty, 518 FTE staff B.S., A.S. and certificate degrees in over 100 majors Specialize in vocational and technology-based education Strong focus on small class sizes and hands-on instruction www.pct.edu
  • 3.
  • 4.
    IT Infrastructure 2,600 College-owned computers, 1,400 student-owned computers in residential complexes 1,600 computers in 50+ academic computer labs, student to computer ratio of 4:1 Standard computer lab software includes Microsoft Windows XP, Office 2003, NetMail POP3 e-mail system
  • 5.
    IT Infrastructure (cont’d) 1,000 staff/faculty PCs Standard employee image: Windows XP, Office 2003, Novell GroupWise, iSeries client Novell Directory Services (NDS) IBM iSeries mainframe, home-grown legacy administrative applications WebCT, Sirsi, eRecruiting, Raiser’s Edge, Cbord Odyssey, EBMS 25 Novell, 15 Microsoft, 3 Linux, 1 Sun, 1 AIX server
  • 6.
    IT Infrastructure (cont’d)100% Cisco network infrastructure except for Packeteer Packetshaper Fast Ethernet via CAT5 for all building LANs, Gigabit Ethernet via fiber for backbone Dual Cisco 6500s for redundant core Fractional T-3 (30 Mbps) Internet service Dial-up Internet access provided for employees, not students About 50% wireless coverage
  • 7.
  • 8.
    Information Technology ServicesOrganization (50 employees) Desktop Computing Academic Computing Technical Support/Help Desk Technical Writer/Trainer Administrative Information Systems Network Applications Mail & Document Services Media Services Telecommunications
  • 9.
    Post Y2K ITSecurity “Problem” Increasing threats from viruses, trojans, worms, hackers, etc. Lack of security standards No coordinated security response Poor security awareness Minimal security policy No security testing
  • 10.
    The “Challenge” LimitationsBudget Staff Time Large backlog of post Y2K projects Balancing security effectiveness with efficient resource management
  • 11.
    Solution Analysis Dedicatedsecurity staff vs. security team Advantages of team approach: Utilizes existing staff and expertise Spreads/diffuses the importance of security across all functional IT areas Funded through existing budgets Disadvantages: No centralized focus/authority Long lead time to develop expertise Staff time directed away from other projects Not invented here syndrome
  • 12.
    The “Solution” ITmanagement recommended forming a campus “security team.” Each area of the IT department committed one employee and a percentage of its budget. A senior manager was designated to provide leadership and coordination of this team effort. The team met weekly over an initial 18 month period, then bi-weekly. Rotating duty officer/CERT format
  • 13.
    The Context Riskvs. investment Scope and impact for priority Mitigating risk factors Administrative data locked up in IBM iSeries (AS/400) GroupWise e-mail system Institutional policy requiring data files to be stored on network drives Centralized IT management and budget culture
  • 14.
    7-Layer Security ApproachLayer 1 - Physical Layer 2 - Internet Layer 3 - Network Layer 4 - ResNet Layer 5 - Servers Layer 6 - Employee PCs Layer 7 - Social
  • 15.
    Layer 1 -Physical Before Distributed servers, not physically secured, some actually in staff/faculty offices Network components not secured Minimal UPS protection After Most non-academic servers moved to secured data center; backup generator Wiring closets secured UPS for all servers and network equipment
  • 16.
    Layer 2 -Internet Before Internet router with public IP addresses No filtering of ports After Cisco PIX firewall with PAT translation initially, later acquired additional IPs, changed to NAT ( still occasional problems, need an XLATE clear ) Access control list on Internet router ( example ) Packeteer - Although purchased for bandwidth control, provides another layer of “protection” and “detection”
  • 17.
    Internet Router ACLaccess-list 115 permit tcp any 0.0.0.0 255.255.255.0 established access-list 115 deny ip 10.0.0.0 0.255.255.255 any access-list 115 deny ip 127.0.0.0 0.255.255.255 any access-list 115 deny ip 172.16.0.0 0.15.255.255 any access-list 115 deny ip 192.168.0.0 0.0.255.255 any access-list 115 deny ip 224.0.0.0 15.255.255.255 any access-list 115 deny ip host 0.0.0.0 any access-list 115 deny ip 12.23.198.0 0.0.0.255 any access-list 115 deny ip 12.23.199.0 0.0.0.255 any access-list 115 deny ip any 0.0.0.255 255.255.255.0 access-list 115 deny tcp any any eq 135 access-list 115 deny udp any any eq 135 access-list 115 deny tcp any any eq 137 access-list 115 deny udp any any eq netbios-ns access-list 115 deny tcp any any eq 138 access-list 115 deny udp any any eq netbios-dgm access-list 115 deny tcp any any eq 139 access-list 115 deny udp any any eq netbios-ss access-list 115 deny tcp any any eq 445 access-list 115 deny udp any any eq 445 access-list 115 deny tcp any any eq 593 access-list 115 deny udp any any eq 593 access-list 115 deny tcp any any eq 3333 access-list 115 deny udp any any eq 3333 access-list 115 deny tcp any any eq 4444 access-list 115 deny udp any any eq 4444 access-list 115 deny tcp any any eq 69 access-list 115 deny udp any any eq tftp access-list 115 deny tcp any any eq 161 access-list 115 deny udp any any eq snmp access-list 115 deny tcp any any eq 162 access-list 115 deny udp any any eq snmptrap access-list 115 deny udp any any eq 1993 access-list 115 deny tcp any any eq 1900 access-list 115 deny udp any any eq 1900 access-list 115 deny tcp any any eq 5000 access-list 115 deny udp any any eq 5000 access-list 115 deny udp any any eq 8998 access-list 115 permit icmp any any echo access-list 115 permit icmp any any echo-reply access-list 115 deny ip any any log-input
  • 18.
    Layer 3 –Network - Before 10.x.x.x organized geographically; each “building complex” has a subnet; 10.1.x.x, 10.2.x.x, 10.3.x.x, etc. Any to any routing philosophy Simple telnet to devices No central security scheme
  • 19.
    Layer 3 –Network - After 100% VLAN scheme VLANs based on computer/user role Internet style ACLs applied on traffic leaving VLANs Traffic denied entering VLAN if no reason for the traffic Extended today to separate VLANS for point-of-sale stations, HVAC, wireless, dial-up; each with its own ACL SSH required to access devices, coordinated userid/password with Cisco ACS server that LDAPs to our NDS 10.1.x.x network equipment 10.2.x.x servers 10.3.x.x printers 10.4.x.x staff 10.100.x.x ResNet Etc.
  • 20.
    Layer 4 –ResNet Before Normal network subnet No restrictions ISP attitude No scanning After – version 1 Single VLAN ACL limited access to other campus VLANs After – version 2 VLAN per 48 port switch Internet style ACL “rule set” to block known bad ports such as 445 Routine scanning and quarantining
  • 21.
    Layer 5 –Servers - Before Public IP address via firewall conduit Distributed physically No port filtering Inconsistent patch strategy No virus protection Inconsistent HTTPS implementation Many outside of the “network” department No scanning for vulnerabilities No disaster recovery plan
  • 22.
    Layer 5 –Servers - After Servers in data center or managed by server group HTTPS required for any sensitive data Private IP addresses mapped to public via “conduit” in the firewall Port filtered in the firewall, deny all, allow those required for specific services Port filtered coming out of ResNet and student computer labs Managed patch strategy, critical patches applied in 24 hours Symantec Anti-Virus on servers NetMail/CA eTrust anti-virus and RBL filtering for e-mail GWAVA/Symantec Anti-Virus e-mail filtering GWAVA attachment filtering Routine Nessus scanning Comprehensive disaster recovery plan
  • 23.
    Layer 6 -Employee PCs After Private IP address via PAT/NAT Managed Symantec Anti-Virus “ Push” of critical Microsoft security patches via Novell ZenWorks Nessus scanning Before Public IP address No anti-virus No patch management No scanning
  • 24.
    Layer 7 -Social Before Little or no public awareness No AUP Loose user ID and password policies “ It won’t happen here, we know everyone personally After Acceptable Use Policy Accounts blocked after 3 failed log in attempts Passwords changed every 180 days Regular communication via online newspaper Security education classes
  • 25.
    What’s on theradar screen? Spyware PC firewall Instant Messenging issues VPN Network access control Two factor authentication Security as it affects privacy issues E-mail security
  • 26.
    Conclusion Security teamwas the right approach for us Effective, no significant down-time except for Blaster/Welcia, fall 2003 Cost-efficient Diffused security awareness across the department Developed security skills across ITS Security Infrastructure Cisco PIX firewall Packeteer Packetshaper Cisco VLANs/ACLs Symantec Anti-Virus Novell ZenWorks GWAVA Anti-virus/attachment filtering Nessus
  • 27.
  • 28.

Editor's Notes

  • #4 5
  • #11 As a medium-size (6,000 FTE) 2 and 4 year degree-granting institution, Penn College’s IT resources are always stretched to the limit ( not unlike most other higher education IT organizations). We wanted an IT security solution that could work within our current organizational structure, leverage existing staff expertise, not substantially drain our financial resources and yet provide an effective level of cyber-threat protection
  • #13 IT management recommended the formation of a campus “security team.” Each area of the IT department committed one employee from part of their normal assignments to be part of the security team. Each area also “contributed” a percentage of their normal budget to fund the hardware and software. A senior manager was designated to provide leadership and coordination of this team effort. The team met regularly over an initial 18 month period to brainstorm, expand their knowledgebase, investigate solutions, recommend strategies, develop plans, and implement the initial layer of security infrastructure.
  • #20 100% VLAN scheme VLANs based on computer/user role: ITS staff, college employees, computer labs, server farm, ResNet, HVAC, security, network equipment Internet style ACLs applied between VLANs to limit access Student lab PCs can’t “see” staff VLAN ResNet PCs can’t “see” staff VLAN Extended today to separate VLANS for point-of-sale stations, HVAC, wireless, dial-up; each with its own ACL