Transcript Policy Development Process - University System of Maryland

USM Security Day
Jack Suess, [email protected]
http://umbc.edu/~jack/usmsecurity
Rodney Petersen, [email protected]
http://www.oit.umd.edu/~rodney
USM Security Day - October 11, 2001
What We Will Cover
•
•
•
•
•
The challenges of securing our IT infrastructure?
Security as an IT enabler within your organization
Understanding and determining appropriate risk
The role of policies, guidelines, and procedures
Developing a security team, incident response and
detection
• Emerging Technologies
•
• Strategies and ideas for overcoming the challenges we face
USM Security Day - October 11, 2001
Challenges of Securing a Campus
• Most IT security professionals will state that highereducation is the most difficult environment to secure
• Why is this so? Let’s list the reasons below.
– Reputation among hackers as easy
– Students want to experiment
– Residential networks
– Lack of budget
– ……… and many more… lets hear them
USM Security Day - October 11, 2001
Wasn’t that Cathartic?
• If we succeed at doing our job in this seminar you should
leave here with strategies you can use to face these
challenges and feel like you can make progress in securing
your campus.
• If we don’t get your particular challenge(s) addressed then
by all means stop me during the conference or send me an
email.
USM Security Day - October 11, 2001
Why Security is Important
• Higher-education is increasingly reliant on IT for business,
learning, and information sharing throughout the institution
(see E is for Everything (Katz,2001)):
– e-Learning – There is a presumption on the part of
faculty that these systems are secure.
– e-Business –Students presume that the institution is
providing online services securely.
– Research – funding agencies presume that research
data and equipment is secure.
– Collaboration – Internet and email are considered
“utility” services and expected to be there 7x24
USM Security Day - October 11, 2001
Why Security is Important (2)
• The lack of security in higher-education is increasingly a
problem for those outside of higher education.
– Denial of Service (DoS) attacks brought down access to
Yahoo, eBay, and CNN (2/7/2000).
– Attacks on commercial and Federal systems are all-tooften traced back to higher-education
– Pressure is mounting on higher-education to improve
security. Educause established a task force led by
Gordon Wishon and Dan Updegrove to identify bestpractices within higher-education
USM Security Day - October 11, 2001
Security as an Enabling Technology
• Security is often thought of as increasing cost but it can
also be an enabling technology.
– Authentication and authorization are at the heart of
security but are required by other IT initiatives as well.
– One example, central authentication provides a
framework for deploying customized web services such
as a portal.
– Middleware to support security (directory services,
central authentication, and PKI) provides benefits to IT
outside of security by making it possible to identify
users and provide them access to information
USM Security Day - October 11, 2001
Security as an Enabler (2)
• Opportunities avail themselves to organizations that can
take advantage of new technologies (e.g. cable Internet
service and VPN’s, PKI, etc.)
• Security administration is one of the more technical
aspects of system administration and requires staff
performing administration to understand the larger picture
of how systems interoperate. This helps them broadly in
their work, especially in problem resolution.
USM Security Day - October 11, 2001
IT Architecture @ UMBC
• MIT Kerberos 5 for authentication . This provides a
single username/password for these services:
myUMBC portal, administrative applications, Unix,
PC labs, AFS file services, modems, and Resnet
• iPlanet LDAP directory services for self-service
applications controlling email, account generation,
and helpdesk functions.
• Oracle 8i for database services
• Linux, Solaris, and SGI Irix for Unix services
• We have a Microsoft enterprise license for desktops
• Implementing Peoplesoft for business applications
USM Security Day - October 11, 2001
Example of Security as an IT Enabler
• UMBC developed a web-based single sign-on application,
WebAuth, that utilizes our Kerberos authentication server
and LDAP directory to provide authentication services to
web-based applications. UMBC has integrated WebAuth
into Blackboard.
• Directory services drive account creation and user access
to services
• A strong security framework and IT infrastructure allowed
us to role out these new initiatives
USM Security Day - October 11, 2001
Defining Risk -- Background Information
“ We protect our homes and cars in a systematic
manner, perhaps with door and window locks,
intruder alarm systems and car immobilisers. We
think about what the risks are and introduce relevant
countermeasures.” British Department of Trade and
Industry.
• Unless you implement draconian controls and disconnect
from the Internet you have no way of guaranteeing
security.
• Computer security is not a binary decision, instead security
is a complicated balancing game between risks, threats,
and resources.
USM Security Day - October 11, 2001
Defining Risk – Measuring Risk
• As CIO/Director we implicitly work to balance wants,
risks, and resources across many different IT areas
• The measure of success we should focus on is this: are we
doing the best we can with the resources we have?
– What IT assets are most important to protect
– What are the major threats we face
– How can we minimize the threats to our most important
assets
USM Security Day - October 11, 2001
Risk – Identifying and Quantifying
• Methods to identify and quantify risks?
– Formal risk assessment. This is quite time consuming
and/or expensive if outsourced to consultants (think
Y2K) but will be required if we don’t do better
– Utilize state or federal security guidelines (see NIST
FIPS 31)
– Attack vulnerability approach – consider possible
attacks and consequences, calculate annualize loss
expectancy (ALE)
– EDP auditing baseline controls. Every public university
has an outside auditing group review IT practices.
USM Security Day - October 11, 2001
Attack Vulnerability Approach for UMBC
•
•
•
•
•
•
•
•
•
Denial of service. 1 attack per semester
OIT System compromise. 1 successful per semester
Department machine compromise – 2 per semester
Outside probes – 25 per week
Administrative Password sniffing/stealing – 1 every few
years
SPAM – daily complaints
UMBC application compromise – none
Virus issues - daily
Monitor internal OIT access to privileges
USM Security Day - October 11, 2001
Quantifying Risk
• Information required
–
–
–
–
Cost to replace equipment lost (natural/physical disaster)
Opportunity cost of lost business (generally minimal in HE)
Staff cost due to lost productivity
Costs associated with loss of intellectual property
• Qualitative measures
–
–
–
–
Loss of confidence with our students
Loss of confidence by our research partners
Loss of confidence in IT by faculty/staff
Impact on reputation
USM Security Day - October 11, 2001
Quantifying Risk - Methods
• Single Loss Expectancy (SLE) – the costs associated with
a single security incidence
• Annualized Loss Expectancy – SLE times frequency of
occurrence.
• Insurance premium – Actuaries will calculate a premium if
you choose to transfer the risk to an external entity.
USM Security Day - October 11, 2001
Major Areas of Risk
•
•
•
•
•
•
•
Data destruction
Data compromise or theft
Reduced capacity to provide service
Loss of system or network integrity
Loss of system or network accessibility to legitimate users
Diminished reputation.
Loss of revenue
USM Security Day - October 11, 2001
UMBC Review of Risks
• Denial of Service (DoS) – risk is moderate, impact is
moderate, cost is staff time, network bandwidth, and shortterm loss of service. Frequency 1 per semester.
• Central host system compromise – risk is low/moderate,
impact is high/very high, cost is staff time rectifying
breach and loss of customer confidence. Frequency 1 per
year.
• Administrative system compromise – risk is low, impact is
very high, cost is staff time, audit review. Frequency is 1
per 20 years.
USM Security Day - October 11, 2001
UMBC Review of Risks (2)
• Account compromise – risk is low/moderate, impact is
moderate, cost is minimal, changing password and
possibly restoring account files. Frequency 1 per semester
• Faculty host system compromise – risk is high, impact is
low/moderate, cost is staff time rectifying breach and
potential loss of data (though we make a point of data
backup procedures). Frequency of probes 25 per week.
• Residential student host system compromise – risk is high,
impact is low, cost is staff time turning off attack. Probes
25/week
USM Security Day - October 11, 2001
UMBC Review of Risks (3)
• Virus attack – risk is very high, impact is moderate, cost is staff time
rectifying breach and potential loss of data. Freq 100/semester.
• Web server attack – risk is low/moderate, impact is moderate, cost is
staff time and loss of customer confidence. Probed 10/week
• Physical security – risk is low, impact is high, cost is space/access
restrictions. Administrative machines are extremely secure. Never.
• Environmental controls – risk is moderate, impact is very high, cost is
$500,000 to install 200KW UPS and Generator. Will be resolved
spring fall 2002.
USM Security Day - October 11, 2001
UMBC Review of Risks (4)
• Risks UMBC has Chosen not to Take:
– E-Commerce – we outsource to Sallie Mae Solutions
for online tuition payments. We are considering
Yahoo!Store for non-credit courses and simple online
sales
– No direct telnet access to our administrative machines
from off-campus
USM Security Day - October 11, 2001
Avg. Loss Expectancy for UMBC
Risk
SLE
Freq/Yr
Risk Total
DoS Attack
5 days,
$1500
2
$3000
Server
10 days,
Compromise $3000
1
$3000
Admin.
60 days,
Compromise $18000
.05
$900
Account
.5 day, $150
Compromise
20
$3000
Faculty Host 5 days
Compromise
2
$3000
USM Security Day - October 11, 2001
Avg Loss Expectancy of UMBC (2)
Risk
SLE
Freq/Yr
Total
Stu. Host
.5 day, $150
Compromise
20
$3000
Virus
Incident
.25 day, $75
300
$22500
Web Server
5 days,
$1500
0.5
$750
Environment $4,000,000
Controls
+
.025
$100,000
Physical
Security
.01
$40,000
$4,000,000
+
USM Security Day - October 11, 2001
Impact of Risks on Security Planning
• Business contingency planning is a major concern
– Focus on environmental/disaster planning
• Virus protection and user education is becoming a critical priority,
especially for Microsoft Outlook users
• We’ve focused on developing an Intrusion Detection System (IDS) that
allows us to pick up probes and focus resources quickly when we see a
machine is compromised.
• Developed a better linux distribution to reduce linux support
• Being heavily web-based we’ve designed a very secure interface to
administrative systems and we don’t store credit card numbers on
campus
USM Security Day - October 11, 2001
Exercise 1 –
•
Answer the following:
1. Annual cost of dealing with viruses at your institution.
What are you doing to reduce this?
2. How quickly could you have your Data center back
online if it was destroyed by fire?
Does this include your academic/research systems?
USM Security Day - October 11, 2001
Approach to Security at UMBC
• Hackers look for easy prey, lock the doors and they will try
the next house!
– Address the SANS top ten list immediately
– Eliminate all non-essential services from Unix/NT
– Daily we monitor lists for security problems (SANS
Unisog, BugTraq, SecurityFocus)
– Patch OS vulnerabilities or eliminate that service
• Create network regions and define access control policies
• Deploy virus protection to everyone
• Proactively monitor network for probes/attacks
USM Security Day - October 11, 2001
Incident Cost And Modeling
Project (ICAMP)
• ICAMP-1
– Model for Costing IT Incidents
– Committee on Institutional Cooperation (CIC)
• ICAMP-2
– Extend the Model with More Examples
– Classification of Incidents
– CIC plus UMd, Cornell, UT-Austin, UC-Berkeley
USM Security Day - October 11, 2001
Policy Development Primer
• Security-Related Policy Issues
• Model Policy Development Process
with Best Practices
• Definitions and Labels
• Policy Format
USM Security Day - October 11, 2001
Security-Related Policy Issues
•
•
•
•
•
•
•
Security Policy
Acceptable Use Policy
Copyright Infringement
Privacy and Data Security
Disaster Recovery
Business Continuity Plan
Wireless and Airspace Authority
USM Security Day - October 11, 2001
Policy Development Process
1. Pre-Development
2. Development
3. Maintenance
USM Security Day - October 11, 2001
Predevelopment of Policy
• Identify Issues
– Be Proactive!
• Conduct Analysis
– Identify Owners
– Determine Path
– Assemble Team
USM Security Day - October 11, 2001
Development of Policy
• Draft Language
– Agree on Definitions
– Use Common Format
• Get Approvals
– Secure Approvals
• Determine/Distribute/Educate
– Plan Communication
– Put Online
– Provide Searches
USM Security Day - October 11, 2001
Maintenance of Policy
• Solicit Evaluation & Review
– Plan Maintenance
– Encourage Feedback
– Archive Changes
• Plan Measurement & Compliance
– Measure Outcomes
USM Security Day - October 11, 2001
What To Call It
•
•
•
•
•
•
•
•
Policy
Code
Rule
Standard
Guideline
Procedure
Protocol
Practice
USM Security Day - October 11, 2001
Policy Format
•
•
•
•
•
•
•
Purpose Statement
Policy Statement
Definitions
Procedures
Related Information
Responsibilities and Contacts
Policy History
USM Security Day - October 11, 2001
Security Policy Resources
• Association of College & University
Policy Administrators (acupa)
www.umd.edu/acupa
• EDUCAUSE Security Task Force
www.educause.edu/security
• National Institute of Standards &
Technology (NIST) Computer Security
Resource Center
http://csrc.nist.gov/isptg/html/ISPTG-1.html
USM Security Day - October 11, 2001
Policy Development Exercise
USM Security Day - October 11, 2001
Incident Detection and Response
USM Security Day - October 11, 2001
Developing a Security Team –
Defining Functions
•
What security functions need to be performed?
1. Handling security incidents – interfacing with campus legal
2. Staying on top of latest security problems
3. Developing security infrastructure and network access plans
4. Developing a central logging and event notification system
5. Developing a central authentication /authorization system
6. Developing a application security framework
7. Developing policies and procedures
8. Updating OS vulnerabilities and virus eradication
9. Educating users on security and safe computing
USM Security Day - October 11, 2001
Security Functions Associated with
Different Positions
• Manager of IT Security – responsible for coordinating
activity amongst IT staff, analyzing risks, coordinating
incidence response, and developing the security
infrastructure. Regardless of campus size, there needs to be
a position focused on security within IT.
• Security Analyst – a technical position focused on
developing and updating intrusion detection systems, event
logging, and assisting the security manager in incident
handling. Some larger institutions have security analyst’s
focused on each OS. Smaller institutions would probably
not need this position.
USM Security Day - October 11, 2001
Security Functions Associated with
Different Positions (2)
• Information Architect – Develops infrastructure plans,
including security framework, for the organization.
• System Administrator – Responsible for administering
an OS, monitoring security and performance, and
verifying security patches are installed
• Network Engineer – Responsible for development of
the network infrastructure and access to the network.
• Director of Policy – Many large institutions have a
Director of Policy that reports to the CIO and is
responsible for policy development and planning.
• DBA – Monitors and oversees DBMS security
USM Security Day - October 11, 2001
Security Functions Associated with the
CIO
• CIO’s have to consider security as importantly as ERP,
advanced networking, and courseware systems
• Role of the CIO/Director
– Sets budget priorities within IT
– Determines organizational structure and job
responsibilities within IT
– Develops IT strategic and operational plans in
conjunction with advisory groups
– Communicates with senior administration and faculty
on the possibilities that IT provides the institution
USM Security Day - October 11, 2001
UMBC Staffing Strategies
• Presently, the Office of Information Technology has
70 full-time staff and approximately 100 students
• Manager – IT Security reports to the Director of
Infrastructure and Support Services and has a dotted line to
the CIO
• Security specialist to assist manager in incident handling,
documentation, and system administration training.
• UMBC has been heavily involved in SANS, we’ve been
active since the mid-90’s and my two security staff teach
the GIAC certification classes.
USM Security Day - October 11, 2001
UMBC Staffing Strategies (3)
• At UMBC, we have found that the staff selected for
participating in the security team feel it is an honor.
Security is one aspect of each respective area that separates
the guru from the average administrator or engineer.
• We provide additional training opportunities in security for
those participating in the security team. We also are
looking at mandatory security training for all system
administrators on campus
• All sysadmins are expected to prioritize OS security
patches over other work.
USM Security Day - October 11, 2001
Staffing Strategy for a
Small Institution
• The CIO/Director must make security an IT priority
– Revamp job descriptions to include security roles
– Identify someone to manage IT security activities
– Budget money for a virus site license
• Integrate security into your IT staff development efforts
• Consider hiring graduate students or undergraduates to
research security practices
• Consider outsourcing IDS and firewall management
services to a outside provider
USM Security Day - October 11, 2001
Staffing Strategy for a
Large Institution
• CIO must make security a priority
– Develop a security policy to require decentralized IT
units to adopt best practices by providing incentives
– Develop written guidelines and procedures to share
with decentralize IT staff
– Establish a security unit with a Manager of IT Security
• Developing coordination and communication between
units is the challenge, regular meetings are important
• Develop a security testbed for deployment of security
services such as IDS, firewalls, and virus detection
USM Security Day - October 11, 2001
USM Security Day - October 11, 2001
Intrusion Detection and Response
How to Find the Problems Before Anyone Else
Does.
Adapted from a presentation by Anderson Johnston
UMBC IT Security Manager
USM Security Day - October 11, 2001
The Trilogy of Security
•
Managing IT security in higher education is a balancing act of three
components.
– The traffic you block from entering/exiting your
network through firewalls and router access control lists
(ACL’s)
– Proactive monitoring of security threats vis-à-vis
system configuration management
– Reactive response to security compromises or probes.
•
•
The more restrictive you are with traffic management the less reactive you
have to be to deal with outside scans and probes.
The more traffic you block the less your end-users can experiment and
collaborate, potentially restricting academic and research productivity
USM Security Day - October 11, 2001
USM Security Day - October 11, 2001
Finding Your Point of Comfort
• Restricting traffic to and from your institution requires a detailed
understanding of what that traffic is and who is doing what
• Restricting traffic has implications to research, residential networks,
and academics
• You can block a moderate amount of traffic through router ACL’s with
almost no impact to users and significantly improve security
• Restrictive access requires policies and executive support if you are
going to be highly restrictive. Even with this it is next to impossible to
adopt stringent firewall policies because much of our traffic is
externally focused
USM Security Day - October 11, 2001
Host Configuration
• Desktop OS’s such as Win2000 and Linux provide a vast array of
services which are turned on by default
• Most host security compromises are now a result of the machine not
being up to date on security patches
• The average person often has no idea they are even vulnerable to these
security problems
• Most security vulnerabilities are not widely disseminated and unless
you know where to look you won’t find out your system is even
vulnerable.
USM Security Day - October 11, 2001
Tips for Reducing Desktop Complexity
•
Provide incentives to users to use central services
– Promote desktop standardization as much as possible
through support incentives. Turn off unneeded services
– Provide web/network services needed by users on
central servers.
•
•
Focus proactive monitoring on central servers
Have tools available to react to issues
USM Security Day - October 11, 2001
What We Are Up Against
• Most hackers are not experts and use standard toolkits, referred to as
rootkits to do attacks.
• Most attackers are looking for easy targets and often have no malice
towards those they attack. If your door is locked they will to to the next
site.
• The attack takes the following form:
– Map a network by OS and open services
– Use a rootkit aimed at a particular OS/service
and try to compromise the host.
– There is often a day or more between mapping
a network and trying to compromise hosts, use
that time to patch
USM Security Day - October 11, 2001
What We Can Do
Think like hackers and adopt a similar strategy
1. Watch security sites for security problems identified on
different OS’s
2. Map our network looking for that OS/service and make
sure it is patched
3. Use an Intrusion Detection System to look for traffic
patterns that are out of the ordinary or that match certain
patterns. Verify that host is not compromised.
USM Security Day - October 11, 2001
Network Mapping - SuperScan
• Windows software
• http://www.foundstone.com/rdlabs/proddesc/superscan.ht
ml
• Flexible configuration of IPs and ports
• Optionally reports host responses
USM Security Day - October 11, 2001
Network Mapping - SuperScan
USM Security Day - October 11, 2001
Network Mapping - SuperScan
USM Security Day - October 11, 2001
Network Mapping - nmap
•
•
•
•
•
•
Unix software (primarily)
http://www.nmap.org
Flexible configuration of IPs and port
Wide range of probe types
Optional O/S signatures
Optional “machine-readable” output (easily parsed)
USM Security Day - October 11, 2001
Network Mapping - nmap
nmap -sS -O -v -v -T Aggressive -oM net_256.out 130.85.256.2-254
•
•
•
•
•
•
-sS
-O
-v
-v –v
-T
-oM
Syn Scan
O/S signatures
verbose
annoyingly verbose
Timing
“Machine Readable” output file
USM Security Day - October 11, 2001
Network Mapping – nmap
Host: 130.85.256.82 ()
Status: Down
Host: 130.85.256.91 ()
Ports: 23/open/tcp//telnet///,
515/open/tcp//printer///, 9100/open/tcp//jetdirect/// Ignored
State: closed (1520) Seq Index: 1 OS: HP LaserJet 5
Host: 130.85.256.94 ()
Ports: 139/open/tcp//netbios-ssn///
Ignored State: closed (1522)Seq Index: 0 OS: Windows
NT4 / Win95 / Win98
USM Security Day - October 11, 2001
Network Intrusion Detection System
• These systems look at packet headers and log information based on “rules”
• These systems can log information to a database for statistical anomalies
• There are commercial and open source tools.
– ISS is a commercial tool that is easy to use and provides a
number of pre-defined reports. ISS also provides
consulting support and you can outsource security
monitoring.
– SNORT is an example of an open source tool. Snort has a
active community of security professional using it. It is
more work to configure but may offer more flexibility
USM Security Day - October 11, 2001
Integrating Tools – A Case Study
• Network Intrusion Detection System (Snort) reports
activity suggestive of NIMDA or other IIS compromise
• Subnet known for configuration issues
• Scan of subnet for port 80 finds IPs of web servers
• Testing finds at least one clear compromise
USM Security Day - October 11, 2001
NIDS based on Snort
– Rule tripped was:
alert udp $HOME_NET any <> $EXTERNAL_NET 69
(msg:"TFTP - Internal UDP connection to external tftp
server";)
– Daily Summary Report:
TFTP - Internal UDP connection to external tftp server
17
– Detailed Report
09/21-09:15:41.568274 [**] TFTP - Internal UDP connection to
external tftp server [**] 130.85.256.9:2438 -> 130.107.6.25:69
09/21-09:16:10.573802 [**] TFTP - Internal UDP connection to
external tftp server [**] 130.85.256.9:2445 -> 130.107.6.25:69
USM Security Day - October 11, 2001
Subnet Scan - SuperScan
+ 130.85.256.7
|___
21 File Transfer Protocol [Control]
|___ 220 oce_twe Microsoft FTP Service (Version 4.0)...
|___
25 Simple Mail Transfer
|___ 220-oce_twe.umbc.edu Microsoft SMTP MAIL ready at Sat, 22 Sep
2001
19:20:55 -0400 Version: 5.5.1877.197.19..220 ESMTP spoken he
|___
80 World Wide Web HTTP
|___ HTTP/1.1 401 Access Denied..WWW-Authenticate: Basic
realm="130.85.256.7"..Content-Length: 644..Content-Type:
text/html....
+ 130.85.256.8
|___
80 World Wide Web HTTP
|___ HTTP/1.1 200 OK..Server: Microsoft-IIS/5.0..Content-Location:
http://130.85.256.8/index.html..Date: Sat, 22 Sep 2001 23:09:58 G
+ 130.85.256.9
|___
25 Simple Mail Transfer
|___ 220 dpet-nt1 Microsoft ESMTP MAIL Service, Version:
5.0.2195.2966
ready at Sat, 22 Sep 2001 19:06:56 -0400 ..
|___
80 World Wide Web HTTP
USM Security Day - October 11, 2001
Subnet Scan - nmap
Host: 130.85.256.7 (goahe.umbc.edu) Ports: 21/open/tcp//ftp///, 25/open/tcp//smtp///,
42/open/tcp//nameserver///, 80/open/tcp//http///, 135/open/tcp//loc-srv///,
139/open/tcp//netbios-ssn///, 443/open/tcp//https///, 465/open/tcp//smtps///,
1032/open/tcp//iad3///, 5631/open/tcp//pcanywheredata///
Ignored State: closed
(1513) Seq Index: 2
OS: Windows NT4 / Win95 / Win98
Host: 130.85.256.8 (adnt.umbc.edu) Ports: 80/open/tcp//http///, 135/open/tcp//loc-srv///,
139/open/tcp//netbios-ssn///, 443/open/tcp//https///, 445/open/tcp//microsoft-ds///,
1025/open/tcp//listen///, 1030/open/tcp//iad1///, 5631/open/tcp//pcanywheredata///,
6666/open/tcp//irc-serv///, 7007/open/tcp//afs3-bos/// Ignored State: closed (1513)
Index: 11367
OS: Windows 2000 RC1 through final release
Host: 130.85.256.9 (ry.umbc.edu)
Ports: 25/open/tcp//smtp///, 80/open/tcp//http///,
135/open/tcp//loc-srv///, 139/open/tcp//netbios-ssn///, 443/open/tcp//https///,
445/open/tcp//microsoft-ds///, 1030/open/tcp//iad1///, 1032/open/tcp//iad3///,
6666/open/tcp//irc-serv///, 7007/open/tcp//afs3-bos/// Ignored State: closed (1513)
Index: 14986
OS: Windows 2000 RC1 through final release
USM Security Day - October 11, 2001
Seq
Seq
Subnet Scan - Results
• Since we are looking for NIMDA-like activity, we are
interested in IIS servers (Windows & port 80)
• Both scanners have located the systems on subnet 256 that
offer port 80 services
• Both can scan for port 139 as well, helping to identify
Windows systems
– Additionally, nmap identified Windows systems
through O/S signatures
USM Security Day - October 11, 2001
Vulnerability Testing
• NIMDA probes for several vulnerabilities, the first four of which are
the result of CodeRed II infection
• The simplest way to check a system is to probe for the same
vulnerabilities.
• As a working assumption, any CodeRed II infected system has
NIMDA as well
• Any web server that responds to command below is infected:
GET /scripts/root.exe?/c+dir
USM Security Day - October 11, 2001
Vulnerability Testing – nmap Output
• Since we ran nmap on Unix, we will collect the appropriate IPs from
the nmap output and feed them into a Perl script that runs the test for
us.
# grep "80/open“ net_256.out | cut -d" " -f 2 > ips
# code_red_II_scan ips >net_256_crII_vuln
USM Security Day - October 11, 2001
Vulnerability Testing – nmap Output
• From the vulnerability scan:
DEBUG 130.85.256.9: receiving...
RESULT 130.85.256.9: COMPROMISED (08/24/2001 12:38p) 5.0
TYPE
130.85.256.9: Microsoft-IIS/5.0
DETAIL 130.85.256.9: : HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Sat, 22 Sep 2001 23:30:30 GMT ContentType: application/octet-stream Volume in drive C has no label. Volume Serial Number is A03F-52C2
Directory of c:\inetpub\scripts
08/24/2001 11:54a
<DIR>
.
08/24/2001 11:54a
<DIR>
..
09/18/2001 09:42a
57,344 Admin.dll
08/24/2001 12:38p
236,304 root.exe
09/18/2001 09:42a
57,344 TFTP1700
3 File(s)
350,992 bytes
2 Dir(s)
7,609,970,688 bytes free
• Bingo!
USM Security Day - October 11, 2001
Vulnerability Testing – SuperScan Output
• While there is a Perl for Windows, it is not as common as
Perl for Unix
• We will test using a web browser
http://130.85.256.9/scripts/root.exe?/c+dir
• Save result to a file
USM Security Day - October 11, 2001
Vulnerability Testing – SuperScan Output
Directory of c:\inetpub\scripts
08/24/2001
08/24/2001
09/18/2001
08/24/2001
09/18/2001
11:54a
<DIR>
.
11:54a
<DIR>
..
09:42a
57,344 Admin.dll
12:38p
236,304 root.exe
09:42a
57,344 TFTP1700
3 File(s)
350,992 bytes
2 Dir(s)
7,609,892,864
• Bingo!
• Note that the timestamps of the files give us probable
reference times to check against the logs for the CRII and
NIMDA infections.
USM Security Day - October 11, 2001
A Little Follow-up –
Sam Spade
• Sam Spade is a Windows utility for digging all the
information about an IP out of the Internet
• Remember that the original TFTP traffic was to
130.107.6.25
USM Security Day - October 11, 2001
A Little Follow-up –
Sam Spade
USM Security Day - October 11, 2001
A Little Follow-up –
Sam Spade’s Log
09/22/01 18:50:37 Spade Log
09/22/01 18:51:45 IP block 130.107.6.25
Trying 130.107.6.25 at ARIN
Trying 130.107.6 at ARIN
SRI International (NET-SRI-CSL-NET-2)
Computer Science Lab
Menlo Park, CA 94025
US
Netname: SRI-CSL-NET-2
Netblock: 130.107.0.0 - 130.107.255.255
Coordinator:
Network Facilities
(650)859-4751
Fax- - - (650)859-2844
(NF2-ORG-ARIN)
[email protected]
Record last updated on 16-Mar-1999.
Database last updated on 21-Sep-2001 23:19:44 EDT.
USM Security Day - October 11, 2001
Network Mapping –
Recommended Practices
• Regular scans of network for particular services
– Use results to schedule systems patches and targeted
vulnerability checks
– Check results of mapping scans against firewall
configurations.
• Scan new installations and upgrades for all services
USM Security Day - October 11, 2001
Summary Recommendations on Incident
Detection
•
•
•
•
Block what traffic you can from your network.
Create network regions based on security.
Limit the services being run on desktop systems
Assign someone to monitor security sites for OS
vulnerabilities
• Use network mapping tools to look for vulnerable hosts
matching that OS vulnerability
• Setup an IDS to look for “odd” traffic and focus attention
on those systems
USM Security Day - October 11, 2001
Concluding Comments
• There are great, free, simple network security tools
available for both Windows and Unix
• You never really know what is running on your network.
• You can find out!
USM Security Day - October 11, 2001
Incident Handling
• There should be a very small group of staff that handle all
incidents. Include university legal, student judicial
affairs,IT, and possibly campus police in reviewing
procedures.
• Define the procedures upon which administrators can
examine files and take action to lock out users
• Separate investigation from judgement of guilt.
• Make certain you document all actions you take.
USM Security Day - October 11, 2001
Incident Handling at UMBC
• Manager of IT Security handles incidents
• Incidents are reported to CIO, university counsel, and
student judicial affairs (if a UMBC student is involved)
• For incidents by UMBC students the CIO has the option of
meeting with the student and if working out a fair
punishment. Student always has option to take case to
student judicial affairs.
• For minor incidents we let student off with a warning,
more serious incidents we require community service
• Any threat of physical harm is referred to police
USM Security Day - October 11, 2001
Handling a Hacking Incident
• You receive a report that some IP address on your network
is currently attacking another site. What do you do?
• Change this to a report that yesterday, but not today, an IP
address from your network was attacking another site.
What do you do?
USM Security Day - October 11, 2001
Getting Buy-in From
Faculty
• Responsibility of the CIO/Director requiring an
educational campaign on many fronts
– Discuss security in the context of your academic course
management servers from WebCT or Blackboard. What
would you do if they were compromised?
– Discuss security with your funded researchers, find out
what security requirements the funding agencies have
– Discuss security with your advisory groups in terms of
reviewing written guidelines and procedures to policies
– An IDS is helpful to showing threats, demonstrate how
easy it is to break into a system
USM Security Day - October 11, 2001
Getting Buy-in From
IT Staff
• This is critical and often over-looked
• Starts at the top, staff sense what their bosses care about
• Embedding security into your culture requires your IT staff
to change the way they do their job and usually requires
training in new skills
• In a decentralized environment this requires demonstrating
ways that using security can save time for overburdened
staff. Providing training is a good approach.
USM Security Day - October 11, 2001
Getting Buy-in From
Executives
• The responsibility of CIO/Director. Either you have the ear
of the executives. If so, then use that to educate them. If
you don’t have their ear then get others to give the message
• Security, like all IT initiatives, has to be discussed in the
context of achieving organizational goals. At UMBC:
– Recruitment of best students. They want services, focus
on security as an IT enabler
– Research productivity. We do $$$$ with NASA and
NSA, that could be jeopardized
– Management. We’re spending $$$$$ on Peoplesoft to
improve administrative applications.
USM Security Day - October 11, 2001
Getting Buy-in From
Executives (2)
• Approaches. My President serves on many corporate
boards and has been introduced to some security issues
through that activity.
• Inviting an executive from a local IT company to speak to
campus leaders about security at breakfast or lunch.
• Find a conference you can invite your bosses to that will
help educate them.
• Find faculty members they respect and educate them
• Invite in a consultant, possibly through Educause, to
review plans and provide feedback to executives
USM Security Day - October 11, 2001
Strategies- Education is Easy To
Break Into
• Address the SANS top ten list
• Set up network regions, create a network region with your
most important IT assets and protect that through
restrictive Cisco ACL’s or a Firewall
• Identify important services you provide and have the
administrators of those machines verify the servers are up
to date with the latest OS patches
USM Security Day - October 11, 2001
Strategy – Students Want to
Experiment
• Having little tolerance for student security infractions can
be handled in a way that promotes educational goals.
• I work closely with Student Judicial Affairs and the
Manager of IT Security. At UMBC we do this:
– On your first infraction the student can meet with me or
be referred to judicial affairs. If the offense did little
harm and did not involve academic dishonesty then
– If the student admits guilt they get probation but they
have to perform community service or write a paper
– If they are caught a second time we refer them to
judicial affairs
USM Security Day - October 11, 2001
Strategy – Our School Only has Liberal
Arts Majors so we are Protected
• One word, MP3. Half the students I meet for security
violations at UMBC are liberal arts majors. The tools
hackers use don’t require advanced degrees. These are
tools that anyone can utilize.
• I am glad to say that the overwhelming majority of hackers
are from off-campus. As a result, it doesn’t matter what
your campus focus is, instead, are you an easy target and
do you have anything of interest to hackers?
• Virus issues do not know any boundaries. If you students
don’t understand technology and don’t take precautions it
can make matters worse.
USM Security Day - October 11, 2001
Strategy – Residential Networks are
Impossible to Secure
• Design is everything
• Look at upgrading to switched network ports over shared
to protect from packet sniffing
• Integrate authentication into your design. Your network
admin should be able to tell you what person is assigned
what IP address at any given time. If not, you have a
problem.
• Alternately, make your residential network appear as an
ISP to your campus
USM Security Day - October 11, 2001
Strategy – Lack of Budget
• Cost of security should be bundled into the initiatives you
are doing and not considered as add on costs. Example,
when developing a portal the cost of creating a single
campus-wide authentication strategy should be integrated
into the total cost. At UMBC, the operating budget for
security is less than $20,000 in equipment for the IDS.
• Review the Average Loss Expectancy (ALE) section and
calculate the cost of not doing this
USM Security Day - October 11, 2001
Strategy – Dealing With Researchers
• Research faculty are under intense time pressure and
budget pressure. Find ways to help with these:
– Develop or purchase a security scanner that will
identify known problems and let the researchers know
of problems on their boxes
– Provide resources to make updating their boxes easier
– If using Linux, provide support to use a hardened
version of Linux. We provide our researchers a CD
– Take time to demonstrate how easy this is to break in
– Be there to help when they are broken into, make a
friend 
USM Security Day - October 11, 2001
Strategy – My Staff Aren’t Technical
Enough
• First, most hackers aren’t highly technical. They use tools
but don’t really understand them. Lock the doors and they
go elsewhere.
• Second, the “T” in IT stands for technology and we have to
assume our staff can do this. Most security related
functions do not require a CSEE major and can be readily
overcome with training. Believe in your staff!
• Third, undergraduates and graduate students can be great
technical resources for staff.
USM Security Day - October 11, 2001
Strategy – IT Staff in Other Units
Don’t Prioritize This Activity
• Create an educational campaign amongst administrators.
Ask them what they will do when your campus is written
up in the Chronicle as Indiana University has been
• Develop an institutional security policy that requires that
all IT resources be secured.
• Provide training to decentralized IT staff on best practices
• Provide support services that help these units take on this
additional burden
USM Security Day - October 11, 2001
Strategy – My Campus is to Small to
Have Hackers Care
• If you still feel this way after this lecture I failed 
• The Security through obscurity strategy. To some extent
there is some truth in this. Hackers do look for bigger
schools for DoS attacks. For storing copyrighted material
they don’t care about size and prefer to operate in
unnoticed places. The DMCA makes this risky now
• The risk in using security through obscurity is that it will
ultimately get you at the worst possible time. This is
analagous to financial managers saying we don’t have to
observe audit regulations because we won’t be audited.
USM Security Day - October 11, 2001
Strategy – I Can’t Find or Keep
Security Staff
• Marine approach. People like a challenge and there is no
bigger challenge for someone in security than highereducation. Recruit people that want to be part of highereducation.
• Develop your own staff. Creating a broad-based security
team provides opportunities for others to fill in when
someone leaves.
• Work with your CS or MIS department to offer a special
topics course on security. This will help identify students
you can look at hiring
• Provide opportunities for professional development. This is
a dynamic field an people need continual training.
USM Security Day - October 11, 2001
Strategy – My Campus Won’t
Approve Any Policies
• First, this is normal. Policy development and ratification is
hard work. For some campuses it is harder than others.
• If you can’t get policies approved shoot for guidelines or
practice statements. They don’t have the legal stature of
policies but are better than nothing.
• Being too specific or putting too much into a policy can
make it more difficult to be approved. Review EFF
critiques listed earlier to understand prior concerns
USM Security Day - October 11, 2001
Strategy – Peoplesoft Will Take Care
of Improving Security
• At UMBC, the joke is that any problem we have, from
grants accounting to improving student life on weekends
will be fixed by PeopleSoft 
• That said, most ERP packages and this includes Peoplesoft,
actually complicate security. These are monolithic
packages that think they know how everything should be
done and often do not have the flexibility desired by
higher-education
• Packaging security upgrades with ERP is a good strategy if
it can be done.
USM Security Day - October 11, 2001
Evaluation
• What did you find most useful?
• What did you find least useful?
• Comments and Suggestions?
USM Security Day - October 11, 2001