Talking points Attacks are more frequent, more aggressive, require more time to repair and prevent Machines get compromised in 2003 for the same reasons they did in 1990: bad passwords, unpatched software (CERT)

Talking points cont. Cost of attacks includes lost productivity, time to fix machines, time to research incident and create response strategy, potential legal liability Assume 4 hours average to repair or rebuild a machine hit with an automated exploit like Nimda or Blaster; frequently lost productivity is longer term; does not include time to research & design recovery strategy

Bad passwords CERT advisory 1990: no password or default passwords second highest reason for successful compromises Spring 2002: machines at Stanford compromised through weak or nonexistent passwords Response: scan proactively for Windows systems with bad passwords (2 people 1 week to research & configure; ongoing management & communication)

MS SQL Slammer (1/25/2003) Exploits MS DB servers without patch for MS (7/2002) – 6 months from vuln to exploit About 50 Stanford machines infected – buggy code not installed by default – but many users hit because they didn’t know they needed the patch (200 hrs) Response – block SQL Server traffic at border between SUNet and Internet (1 person, 1 hour – plus research)

Bugbear (6/6/2003) Virus infects machine if user double-clicks attachment; spreads automatically if MS not installed (available March 2001 – 2+ years from vuln to automated exploit) Confidential data (human resources records, health care information) randomly sent to external addrs – NB CA privacy law in effect on 7/1/2003

Bugbear cont. Campus SMTP service completely disabled for 9+ hours to prevent loss of confidential information Long-term: campus SMTP service completely redesigned to require all on campus to pass through centrally managed anti-virus servers

Bugbear cont. Cost of response: 10 ITSS staff for 3 days (immediate research and response); ongoing communications with distressed users (those infected by virus and those impacted by change in architecture) Only 20+ machines known infected on campus

RPC Hell (8/2003 to present) Microsoft announces critical Windows vulnerability 7/16/2003 Vulnerability is accessible to anyone with network access to unpatched machine Stanford has blocked that network access at perimeter for over a year

RPC Hell (8/2003 to present) Stanford sees first attacks 7/30/2003 (2 weeks from vuln to exploit) despite perimeter filtering – brought in by laptop? Because early attacks were not widespread, we did more “basic research” – no info from Symantec or other “usual suspects” – and had to develop our own recovery strategy

RPC Hell cont. 10 exploits known for July 2003 vulnerabilities, including Blaster & Welchia 7 exploits seen “in wild” at Stanford machines infected  14 man years to repair & restore to functionality Over 100 pages of documentation published

RPC Hell cont. 20 managers & architects from ITSS, schools & departments in average 2 hours of meetings per day for two weeks to develop response (400 hours) New network registration system developed and implemented in ResComp before return of students

RPC Hell cont. Automated system to detect unpatched and/or infected machines and encourage rapid repairs deployed, may be leverage- able for other (future) vulnerabilities & exploits Increased attention to centralized software management, at least for Windows machines

Summary Time from vuln announcement to automated exploit is getting much shorter Incidents require increasingly “violent” ITSS intervention and response Numbers of compromised machines are going up a lot – compare in spring of 2002 to with RPC exploits Legal liability is much higher thanks to new laws