27
Office of Information Technologies Christopher Misra Rick Tuthill Network Architecture SIG Southbridge, MA 10 October 2008 Architecting Campus Network Security

Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

Office of Information Technologies

Christopher Misra Rick Tuthill

Network Architecture SIG Southbridge, MA 10 October 2008

Architecting Campus Network Security

Page 2: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

2

Session Abstract

Various compliance and data security requirements have pushed many campuses to offer managed firewall services to their campus communities. These service can be delivered in a variety of forms and designs with varying degrees of success and adoption. However, the fundamental goal that we are trying to reach is applying reasonable, but secure, controls to appropriate networks and hosts. As part of this deployment, many campus business practices are brought to light that have avoided scrutiny in the past.

Page 3: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

3

Outline

  This session will review a campus-based approach to implement an opt-in managed firewall service, and specifically address the many business process challenges that require effort and education to make secure.

Page 4: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

4

Guiding Principles of Network Design

  Open Network Bias – research needs, historical academic freedom, open standards and interoperability concerns, vendor lock, etc.

  “Unrestricted” On-Campus Access   Equitable Use of WAN Resources (expensive)   Content-Agnostic Approaches   Restrict Access to UMass Community   Accountability Required (Virus, DMCA, etc.)   Migrating Towards “Protecting” Sensitive Network

Resources – regulatory compliance, data holder responsibilities, legal exposure, etc.

Page 5: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

5

Current Network Design Overview

  Tiered Design •  Jack which is assigned to a •  VLAN/IP Subnet which segments traffic at a •  Noderoom Switch which is trunked to a •  Lead/Building Switch which uplinked to a •  Major Aggregation Site which connects to •  Core Transport which delivers to •  Destination (Service, WAN site, etc.)

Page 6: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

6

Motivation for change

  Currently, the network works. It provides basic service in a friction-free, consistent, and scalable manner

  Workflows and trouble ticketing are well-defined •  User <-> Help Desk <-> Telcom <-> Networking

  Security Requirements are not well defined (yet) •  PCI-DSS is a reality •  Data breaches are a ongoing challenge (MGL Ch 93H) •  ISO 27000 is coming…

Page 7: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

7

Limitations of Current Network Design

These limitations are not necessarily security limits, but are manifested as changes needed for security and compliance

  Point-to-point “non-routed” VLAN transport limited to core network sites •  Therefore “overlay network” required for point-to-point

transport

  Redundancy/complexity issues with overlay net •  Troubleshooting issues becomes much more complex

  Transport Speed Limitations •  Currently 1xGigE backbone, 100FX to lead sw in bldg

Page 8: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

8

Our Changing Design Parameters

  High count of “security-required” networks will be identified on campus •  Regulatory compliance concerns will increase (PCI,

HIPAA, FERPA) •  Network-level security perimeters will be required for

many networks   LAN/WAN Bandwidth Requirements will increase

(video) •  Wireless Network Adoption rates will increase (802.11n)

  Real-time network-based applications will increase (security sys, video, VoIP?, etc.) •  Application support requirements may drive changes in

network architecture   Network and Application-level performance

monitoring will be required

Page 9: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

9

IP-as-Transport

  Is already happening for multiple applications •  Door Access Systems •  Environmental Control •  Electrical Power Monitoring •  Elevator Control/Monitoring •  Process Monitoring and Control

  Deterministic network behavior required (failover time/path, latency/jitter/loss, etc.)

  Application support needs may drive changes in network support requirements

  Wired network jack utilization futures are unclear •  Increase, Decrease, Steady state?

Page 10: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

10

Current Design Principles

  The challenges lie in the business process, not the technology •  Why is the health center connected the way it currently

is? •  Why do we have a graduate student managing a

network? •  What would audit have to say if they took a look at

this?

  But, the technology is still complex •  It requires an architectural perspective

Page 11: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

11

Network Architecture Principles

  Flexibility and Extensibility •  Ethernet is and will remain primary L2 transport

mechanism •  Ability to carry non-Ethernet/non-IP traffic (Fiber

-channel, GENI, etc)

  “Reasonable” migration mechanism to new core infrastructure •  No flag-day if we can avoid it

  Scalable Core Transport Speeds -- 10Gig through 100Gig+

  Semi-independent of L2/L3 (switched/routed) network infrastructures

Page 12: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

12

Network Architecture Principles

  Optical core is a likely, but not mandatory outcome

  Where does the LAN end? Where does the WAN begin? •  Distinctions blur with optical core

  Requirements for building-level network unclear at this time. •  We can guess and design for maximum flexibility, but

it’s only a guess… •  Fortunately, we have generally guessed well in the past. •  Past performance is no guarantee of future success

Page 13: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

13

What should and should not be…

  What applications must be supported? •  Life-safety: elevator control, alarm sys, voice •  Regulations: Health Care, Police, Credit Cards •  Process control: SCADA

  What do those applications require? •  Implications of failure (Health Care, Police, SCADA) •  Resulting redundancy requirements

•  dual core router, dual fiber, etc. •  Run-time requirements

•  power/generator/UPS, cooling, etc. •  Security needs

•  separate virtual network, encryption, etc.

Page 14: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

14

What should and should not be…

  Appropriate System/Service-level •  Security measures and protective perimeters •  Load-balancing mechanisms for large services •  Resources to support campus needs •  Data/server backup services, off-site storage •  Development and refinement of “community” services

  What applications can we afford to support •  What risk is incurred by not supporting these

applications vs. resources required for support? •  “Can we ever get out of this business?”

Page 15: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

15

The world as it is

  Decentralized system administration practices on campus

  Varying levels of knowledge among existing departmental system administrators

  Varying levels of electronic protection and detection/auditing capabilities on existing computer systems managed within different departments

  Department-level implementation of appropriate business practices to safeguard sensitive data

  Entities purchase solutions “in a vacuum” •  Expect them to be fully supported on the campus

network

Page 16: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

16

The world as it is

  Inconsistent security perimeters   Scalability/maintenance issues with existing

network security perimeters   Lack of detailed visibility into intrusion attempts

and successes   Regulatory requirements lead to forensic needs

•  Legal notification obligations   Migration of security threats into “application

domain” (Web browser, etc.)

Page 17: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

17

Further design parameters

  Must be supportable, scalable, layered •  Single failure should not “fully expose” computer to

compromise   Must be “simple”

•  limited box count, limited staff resources to manage, etc.

  Must support “enough” networks and throughput to provide for projected campus needs

  Must work for networks geographically located anywhere on the campus •  Traditional design poses limitations on function

  Network Access Control (NAC) to provide access only to “authorized” systems •  Where is the perimeter, inside or outside? (or both?)

Page 18: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

18

Making Progress

  This is primarily a business process problem •  Manifest as an enormous technology challenge

  Network proposal would provide •  Central traditional firewall (replaces protected network

ACLs) •  Central Intrusion Detection/Prevention System •  Central Web Application filtering capability to reduce

web-based application threats •  Needless to say, this runs counter to tradition •  But traditions sometimes need updating

Page 19: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

19

This is a campus problem

  OIT must provide •  A secure, resilient, reliable, and robust network

transport and security framework •  Education of staff regarding sensitive/confidential data

handling requirements   Departmental Practices must provide

•  Appropriate business practices for use of computer with access to sensitive data

•  Awareness of sensitive data usage   Business Impact Analysis will be key in driving

changes •  And there is a campus effort on that front

  This is effectively a Risk Management exercise •  Though IT folks don’t have a tradition of speaking in

terms of risk

Page 20: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

20

Crunchy on the outside chewy on the inside

  Network security tools without endpoint security and configurations standards solves only half of the problem

  We need to understand these in terms of controls •  Operating system patches applied regularly •  Application patches applied regularly •  Endpoint agent software installed

•  Host-based firewall/IDS (ISS) •  Anti-virus with central reporting

•  Disk encryption(?)

Page 21: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

21

How do we implement these controls?

  Many of these are just good, common practices •  Others are good practices that are not so common

(yet…)

  We need a consistent set of information security guidelines that we adhere to as a campus •  That both meet control objectives and accommodate

departmental business practices

  We need to raise awareness of: •  Current University policies •  Appropriate sensitive data handling •  Audit needs and requirements

Page 22: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

22

Example Security Control Guidelines

  All accounts must have strong passwords in compliance with the Complex Password Policy. For systems with default passwords for network accessible devices, those passwords should be changed upon first use.

  Networked devices shall run versions of operating system and application software for which security patches are made available, and these should be installed in a timely fashion.

  When readily available and as appropriate for specific operating systems, software to detect viruses and other malware shall be running, up-to-date, and have current definition files installed as appropriate.

  When readily available for specific operating systems, host-based firewall software shall be running and configured to limit network communications to only those services requiring to access to network devices

Page 23: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

23

From 201 CMR 17.00

“Standards for The Protection of Personal Information of Residents of the Commonwealth”

  Regulations for MGL Ch. 93H   While these regulate private industry, there is an

executive order that applies effectively the same rules to state agencies •  Executive Order 504 ”Order Regarding the Security and

Confidentiality of Personal Information”

  These are generally just good business practices   Effective 1 January 2009

Page 24: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

24

17.04: Computer System Security Requirements

(1) Secure user authentication protocols (2) Secure access control measures (3) To the extent technically feasible, encryption of all

transmitted records and files containing personal information that will travel across public networks, and encryption of all data to be transmitted wirelessly.

(4) Reasonable monitoring of systems, for unauthorized use of or access to personal information;

(5) Encryption of all personal information stored on laptops or other portable devices;

Page 25: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

25

17.04: Computer System Security Requirements

(6) For files containing personal information on a system that is connected to the Internet, there must be reasonably up-to-date firewall protection and operating system security patches, reasonably designed to maintain the integrity of the personal information.

(7) Reasonably up-to-date versions of system security agent software which must include malware protection and reasonably up-to-date patches and virus definitions, or a version of such software that can still be supported with up-to-date patches and virus definitions, and is set to receive the most current security updates on a regular basis.

(8) Education and training of employees on the proper use of the computer security system and the importance of personal information security.

Page 26: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

26

This is not just an IT problem

“Policy complements what an Information technology organization can do to reduce risk by making security a part of every employee’s job description”

•  Dennis Devlin, CISO Brandeis University

Page 27: Architecting Campus Network Security...Oct 10, 2008  · From 201 CMR 17.00 “Standards for The Protection of Personal Information of Residents of the Commonwealth” Regulations

27

Questions?

  Thank you for your attention and time.

  We would be happy to take any questions