Transcript Lightning Round Slides 8 MB, Powerpoint Slides Uploaded on 10

Security & Privacy Lightning Round
•
•
•
•
Jamey Hansen: Security Policies at the College Level
Christopher Kessler: Guest Wireless Access
Ryan Turner: Network Access Control at the Edge
Matt Tolbert: Network Information Analysis
NEW! Not in your program!
• Michael Corn: Contract Themes for Data Protection
• Chandragupta Gudena: Securing Data at Rest
Facilitator: David Stack
Authenticated Guest Wireless
Access: Simplicity and
Security
Christopher Keslar
University of Pittsburgh
Background
• Project to implement campus wide
wireless networking 2006 thru 2007
• Faculty, Staff, and Students
• 802.1x Authentication
• Requirement from faculty that we allow
guest access
Concerns with Guest Access
• Accountability
• What service/infrastructure could be
accessed?
• Same network or separate?
• Ease of use
• Guest concept needed to be expandable
How we implemented
• Separate SSID “GUEST-WIRELESSPITTNET” vs. “WIRELESS-PITTNET”
• Captive Portal for Authentication
– Cisco Wireless LAN Controller
– Redirect to a website for authentication
• Required registration and approval for
access
• Restricted outbound to ports 80,443,and
IPSEC
Guest Wireless Account
• Already had a concept of a non-affiliate
account
– Has both a host and an owner
– Expires after a set time period
• Host needed to be Faculty or Staff
• Login name is an email address
• An account could not exist for more than
30 consecutive days
Workflow – Guest Request
Workflow – Host Request
– Submit individual request or bulk
– Eliminate email verification
– Host approval implicit
Guest Request
• Required Fields
• Name
• Email
• Host’s username
• Arrival and departure dates
• Phone number had been
mandatory
Guest Verification
Host Account Management
Acceptable Use and Initial
Password Setting
Guest Wireless Login
Caught in the Middle
University mandates on one side,
Independent faculty on the other
Jamey Hansen
Office of Information Technology
College of Liberal Arts
University of Minnesota
[email protected]
About us
• University of Minnesota
– 66,100 students
– 19 colleges/schools
• College of Liberal Arts
– 18,660 students (largest college)
– 1303 faculty and staff
CLA-OIT
• Regional Technician Support Model
– 12 techs for 40 departments and centers
– Provide individualized support
– Slow evolution to more efficient practices
• CLA-OIT also includes
Software & Web
Research Computing Video Services
Academic Tech
Support
Survey Services
Digital Content
Library
University SPD Standard
•
•
•
•
•
Four years old
Not explicitly for ALL computers
Only IF device stores/access private data
Generally ignored for years
Computer theft meant insurance claim
Awakening
•
•
•
•
Laptop stolen (in Spain!)
Student grades
Letter from CIO
Dean wanted action
Routine
• “Breaches” became routine
• User education
• University-run training
Early Ideas
• Tried to write college-specific security
policies, but…
– No appetite to take ownership
– No desire to limit users’ access
– No agreement on requirements
CLA Policy
• All computers have the potential to contain
or access legally private data and are thus
required to comply…
• Every computer must have an
“Implementation Plan”
• No “opt out” — just custom plans
Implementation Plan
• Provide default plan
– Meets all 18 University requirements
– Does not exceed intent
– Offers more details
– Multiple documents for multiple audiences
• Custom plan option
– Departments or individuals
– Approved if meets University Standard
Thankless Job
• Few faculty thank us for
– longer passwords,
– screen saver locks,
– reduced privileges,
– encrypting their hard drives
• But they do appreciate
– hearing how we help them meet policies
– our attempts to provide alternatives
What Have We Learned
• Take action, but don’t rush
• Facilitate, don’t enforce
• Maintain good relationships
Next steps
• Stay focused
– Serve needs of faculty and staff
– Improve security
• Automated monitoring
– Are all 18 requirements being met?
• Identify better tools and practices
Automated Network Access (NAC) Control at the Edge
University of North Carolina at Chapel Hill
Ryan Turner Oct 2008
--NAC: What is it at UNC
•
•
•
•
•
•
Use the network infrastructure as part of the security solution
Location and identification
Technology to manage voice, video and data end points
Controlled access
Determination of end point health status
Is it?
– Security?
– Management?
– Both!
• Security enhanced network using an intelligent infrastructure with
industry standards products
Automated Network Access (NAC) Control at the Edge
NAC: Challenges & why NAC at UNC?
•
•
•
•
•
•
Open access culture
No political control of end points
Many devices that do not login
Heterogeneous devices/users/departments/requirements
New applications, devices all the time
Need to stop/limit the impact of problem devices in a automated,
semi-automated or manual way quickly
• Security needs to be reactive, proactive yet not put undue burden
on users to get work done
• Save the network - keep most users working
• Save time: users, staff
Building Utilities,
Door Locks, etc.
Medical & Research
Equipment
Automated Network Access (NAC) Control at the Edge
NAC: How (in general)?
• Security enhanced network: Intelligent infrastructure with Security
hooks
• Standards - best of breed products
– TCG/TNC groups
– RFC 3580
– 802.1X
• Extensibility of solution set
–
–
–
–
Programmable
Customize for your environment
Cut features off you do not use
Integrates with other security products: standards based
• Policies on switches: static and dynamic
• At the edge or near the edge: internal advantages
• Link other technologies with NAC
Security Enhanced Network
Automated Network Access (NAC) Control at the Edge
NAC: How (details)?
• Software – Netsight NMS
– Policy Manager
– Automated Security Manager
– NAC Manager
• Hardware: Policy enabled switches enabling
edge, near edge authentication
• Hardware: NAC Gateways
• Hardware: Intrusion Detection (IDS & IPA)
• Manual processes that feed in events:
–
–
–
–
SNORT
Nessus, tests of other scanning software
Copyright notifications – user/device removed
Other problems: duplicate IP, buggy product,
etc.
Server – Netsight NMS
NAC
Switch – end user
Switch - distribution
SNS
Enterasys
NAC
TAG
-ITA
NAC Gateway
Intrusion Detection
Automated Network Access (NAC) Control at the Edge
NAC: How (more details)?
• Automated Processes: Web pages for Security group and
others
– “Smartbox” tool for Security
– “User location” tool for admins
– Captive portal web notification, remediation
•
•
•
•
•
•
•
Policies on switch - Acceptable Use Policy (AUP)
Policies on switch – dynamic change
Primary authentication: MAC based
Blacklisting – drops user/device everywhere
Priority access: ex. provisioning for VOIP
State changes: manual, semi-automated, automated
Web redirect: keep user informed – saves support time
Security Enhanced Network
Automated Network Access (NAC) Control at the Edge
Intelligent Edge: Pre-Connect NAC
Non-compliant asset attempting connection to the network
Netsight Suite:
NAC Manager
NAC Functions
 Detect
 Authenticate
 Assess
 Authorize
 Notify or Remediate
5
Role = Quarantine
1
NAC Gateway
(out-of-band appliance)
4
User Laptop
Enterasys
Matrix/SecureStack Switch
3
Compliance Check
2
Authentication
Server
Thanks to Enterasys Networks for help with content of this poster/slide.
37
Automated Network Access (NAC) Control at the Edge
Intelligent Infrastructure: Post-Connect NAC
Threat on the network after connection
NetSight Suite:
NAC Manager
NAC Gateway
(out-of-band appliance)
NAC Functions
1. Monitor
2. Contain - even after move!
3. Notify or Remediate
3
2
2
1
IDS, NBAD,
SEM, etc
(in or out of band)
Role = Quarantine
3rd Party Switch
Wireless
VLAN = Quarantine
Thanks to Enterasys Networks for help with content of this poster/slide.
Discovering
Network Usage Trends
& Security Risks
Through
Network Information Analysis
Matt Tolbert & Jay Graham
University of Pittsburgh
Sample Netflow Data
15 Feb 05 17:06:17 15
Feb 05 17:06:27
tcp
183.49.60.170
178.78.25.52
22
5190
15 Feb 05 17:06:17 15
Feb 05 17:06:27
tcp
178.78.81.163
178.78.25.52
22
5190
15 Feb 05 17:06:18 15
Feb 05 17:06:28
tcp
178.78.230.141 178.78.25.52
22
61200
15 Feb 05 17:06:18 15
Feb 05 17:06:28
udp
183.48.186.70
178.78.25.52
8
612
15 Feb 05 17:06:22 15
Feb 05 17:06:28
udp
164.173.98.61
178.78.25.52
5
366
15 Feb 05 17:06:19 15
Feb 05 17:06:29
udp
178.51.85.129
178.78.25.52
8
612
15 Feb 05 17:06:27 15
Feb 05 17:06:30
icmp
103.87.114.23
178.78.200.247 2
96
Description

Start day/time

Finish day/time

Packet type

Origination IP

Destination IP

IP protocol

Number of bytes
Malware’s impact on networks
100%
400,000,000
90%
350,000,000
80%
300,000,000
70%
60%
250,000,000
50%
200,000,000
40%
150,000,000
26%
30%
100,000,000
14%
10%
50,000,000
3%
13%
6%
1%
14%
8%
8%
20%
10%
2%
0
0%
2005.08.10
2005.08.09
2005.08.08
2005.08.07
2005.08.06
2005.08.05
2005.08.04
2005.08.03
2005.08.02
2005.08.01
2005.07.31
% Network Bandwidth Used by Compromised Systems
Outbound Bytes Used by Compromised Systems
University Network Bandwidth Used by Compromised Systems
Original “Top 10” Report
Top 100 University of Pittsburgh Source Ip Addresses to non Pitt sites for 2008-XX-XX
Total Bytes
:
442,631,080,683
Number of IP Entries :
17,549
Mean (Bytes)
:
25,222,581
Median (Bytes)
:
357,615
Rank
1
2
3
4
5
6
7
8
9
10
IP Address
136.142.169.153
136.142.5.7
130.49.228.207
136.142.54.63
136.142.11.72
136.142.100.44
130.49.228.206
136.142.103.8
136.142.97.165
136.142.5.12
# Bytes
28,470,493,935
21,974,677,913
19,406,893,242
16,221,104,708
15,169,443,200
14,655,216,086
11,410,501,879
10,792,874,826
8,710,776,037
8,709,923,216
% of BW
6.43
4.96
4.38
3.66
3.43
3.31
2.58
2.44
1.97
1.97
Cum %
6.43
11.40
15.78
19.45
22.87
26.18
28.76
31.20
33.17
35.14
DNS Name
bns-data-01.pitt.edu
portal5.cssd.pitt.edu
pittweb.cssd.pitt.edu
jmr5.dept1.pitt.edu
updates.pitt.edu
minnie.dept2.pitt.edu
ewi-dept.cssd.pitt.edu
jurist.law.pitt.edu
webcam-library.pitt.edu
webmail.pitt.edu
Typical day’s worth of network traffic
Compromised workstation blasting out spam
“Zombified” workstations connecting to botnet controllers
ICMP flood-based denial of service attack
Brute force attack against open SQL ports
Worm propagation
Contract Themes for Data
Protection
Contract Language Project Team: Leslie Maltz, Mary Ann Blair, Michael Corn,
Joanna Grama, Miguel Soldi
Educause 2008
Disclaimer
• The following document, data security themes, and
sample contractual clauses are provided for
informational purposes only and are not to be
construed as legal advice.
• We highly recommend that any intended use of the
sample clauses be reviewed by appropriate university
legal counsel in the full context of the contractual
arrangement prior to communication to the other
contracting party and during negotiation of terms.
Step 1: Recognizing that you
have a Problem
Notwithstanding the foregoing, you understand and agree that by
submitting your Content to any area of the service, you automatically
grant (and you represent and warrant that you have the right to
grant) to
: (a) a royalty-free, worldwide, fully paid-up,
perpetual, irrevocable, non-exclusive right and license to (i) use,
reproduce and distribute your Content within the Service as
permitted by you through your interactions on the Service, and (ii)
use and reproduce (and to authorize third parties to use and
reproduce) any of your Content in any or all media for marketing
and/or promotional purposes in connection with the Service,...
Step 2: What are your Peers
doing?
• Toolkit contains slightly sanitized contract
language in use at:
– Carnegie-Mellon, Columbia, Illinois, Purdue,
UTexas
• Guidelines for usage
– Decision tree
– Criticality ratings
– Thematic categorization
– References
Step 3a: Moving Forward:
Decision Tree for Contracts
• Identify baseline requirements
– e.g., general data protection
• Identify regulatory requirements
– e.g., FERPA, PCI-DSS
Step 3b: Moving Forward:
Decision Tree for Contracts
• Identify policy, procedural, or best practice
requirements
– e.g., notification upon security breach
• Consider situational elements
– e.g., assistance with litigation, audits
Resources
• Data Protection Contractual Language:
Common Themes and Examples
https://wiki.internet2.edu/confluence/display/secguide/Home
•
•
•
•
•
Leslie Maltz [email protected]
Mary Ann Blair [email protected]
Michael Corn [email protected]
Joanna Grama [email protected]
Miguel Soldi [email protected]
Security & Privacy Lightning Round
Contact Information
Jamey Hansen
Christopher Kessler
Ryan Turner
Matt Tolbert
Michael Corn
Chandragupta Gudena
Facilitator:
David Stack
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Chandragupta.Gudena@
bridgew.edu
[email protected]