UCCSC 8/3/04

Pursuit of IT Security

Lessons Learned

Huapei Chen -- Director of IT, EECS

Alex Brown – Project Lead, EECS

Department of Electrical Engineering and Computer Sciences

Univ. of CA Berkeley

Pursuit of IT SecurityLessons Learned

It all started a hot summer day in August, 2003…

What We Had…

Blaster Disaster

2 out of 5 Windows systems in EECS were rebuilt (compromised or unpatched).

Estimate 2000-3000 FTE hours lost (not counting data loss).

65% of grad student laptops were compromised (largest representation of un/mismanaged mobile systems).

User awareness was at all time high AFTER the incident, but misconfigured systems still appear on the net daily

What We Had…

EECS IT Risk Assessment

A month-long, department wide activity, encompassing all aspects of IT services, such as:

– Infrastructure– Application– Operations– People

Does not fare well against corporate environment. Serious lacking in user awareness, IT policy and enforcement, and

“standards” for computing devices. Starting point of the year-long EECS IT security project.

What We Had…

0.00

20.00

40.00

60.00

80.00

EECS IT Risk Assessment Result

BRP Value 74.00 59.00 64.00 54.00

Average 19.60 29.75 34.00 20.83

Result 16.00 23.00 26.00 2.50

Infrastructure Application Operations People

What We Had…

Virus/Spam Too many to mention:

– bagle (32+ variants .a through .ah)– mydoom (13+ variants .a through .m)– netsky (.a through .ac)– soBig, klez, etc.

Many virus are transmitted via email. 55+% of all incoming EECS email are “spam”.

What We Had…

It’s a Jungle Out There…

What We Have?

Active Instructional courses and labs Demanding administrative services Dominant researches:

a) Wirelessb) Motesc) HoneyPotsd) HPC and large computation intensive simulationse) Nano researchf) Microfabricationg) Optical/QoS related networking research

Delicate balance between the needs for stable, 24x7 production services and flexibility and robustness.

Historically, cutting edge research environment defies convention and resists “centralization” or “standardization” of IT.

What We Have?

“Centralized” Infrastructure services:– Networking (wired and wireless)– IP based services– User Account management– Department wide applications– Instructional

“Federalized” tier-1 and tier 2 services:– User level support– Desktop and server management– Application development– Research specific support

Highlight CommunicationsDissemination of informationDifficulty in harboring support and understandingNot streamlined

What We Have?

Various federal and state level laws.– SB-1386– DMCA

UCB Minimum Security Standard.– Patch management– Personal firewall

UCB Data Management, Usage, and Protection Policy.– Classification of all data– Mandatory protection of certain types of systems.

Community buy-inChange in cultureEncouragement and enforcement of “right” behaviorExpensive!!

What We Have?

Many monkeys on our backs…

Realistically…

IRIS (EECS IT organization) reports to a faculty committee led by one Vice Chair.

– Committee meets twice a year– One person makes the high-level operational decision– Takes a long time to build consensus when dealing with substancial policy

changes EECS has 110+ faculty

== 110+ CIOs

Many IRIS operations are supported via fee-for-service model.

What is the right model for us?

Realistically…

Too many chiefs, not enough indians.

Control as Little as Possible

Imposing Order

Original reaction in the wake of Blaster– Strong Perimeter Firewall– Mandatory central management of all systems– Limitations on allowed platforms, services, and

applications.

Reassessment

Perimeter firewall did not fly Does central control make sense?

– A historically decentralized culture– Wildly diverse computing needs– Limited resources for a task that does not scale

How to improve on the decentralized model?

Mandating the Right Things

Policies– Campus plus departmental policies– Technical enforcement– Encouraging compliance

Mandating the Right Things

Network control– Registration of hosts– Identification of POC– Ability to withdraw network access on short notice

Communications channels– Automated contact mailing list for POCs– Mandatory education for incoming students

Releasing Control

Optional centralized services– Full end-node management– Patch management– Antivirus management (host based and email

scanning)– Active and passive network scanning– Education and training

Releasing Control

No central support or mandate– Unsupported operating systems– Specialized applications or services– People who don’t use central services end up here

Plan Ahead

Trends

Volume Sophistication Speed Severity Dependency

Threats

Loss of productivity Loss of data Legal consequences

– Copyright violations– Theft of personal information– Use of facilities as stepping stone

Loss of funding

Conclusions