1. Office of Campus Information Security Incident Response Briefing Jeffrey Savoy, CISSP

2. Roadmap OCIS Incident Response Background Infringement Reports Situational Awareness Reports Information Incident Reporting Policy Nessus Self Service Scans AppScan Self Service Scans

3. OCIS Incident Response Background OCIS Incident Response Reports abuse@wisc.edu Help Desk, NOC, www.cio.wisc.edu, etc 2 FTE and 2 part time students Handle some reports directly and forward others WiscNIC Statistics posted at www.cio.wisc.edu/security Wide range of reports

4. Infringement Reports Volume:

5. Infringement Reports Complainants:

6. Infringement Reports Campus locations:

7. Situational awareness reports A wide variety of reports can be sent to abuse@wisc.edu The following are specific reports that either we signup or implement locally Goal is to reduce exposure time Each source contains different raw evidence Each potential of false positive Based on experience, harder to track in NAT environment We can tune local alerts In most cases, worth investigation

8. Situational awareness reports Web-Spam Searches OCIS has a process that queries Google daily (M-F) for signs web spam on wisc.edu sites. The spam may be indicative of a compromised web server or a site that allows public comments which is being abused.

9. Situational awareness reports Example: “OCIS has identified the below URLs recently found in Google to be consistent with providing or re-directing to web spam.” Include (in part): Why getting this email (WiscNic) Suspicious url What might indicate Google cache removal instructions Statistics: 29 confirmed reports since January 2009 (about 4 a week)

10. Situational awareness reports Sophos Alerts OCIS receives alerts of spam originating from the University of Wisconsin - Madison from Sophos email honeypots installed world wide. Often these alerts are indicative of a compromised personal computer that is being used to send out email spam. We have access to this service as the result of WiscMail purchase of Sophos for filtering.

11. Situational awareness reports Example: “Our spam scanning software has detected the following spam was sent from your network I have attached a part of the raw data below for your review. Please note that all dates and times are in -0700 unless otherwise noted. Could you please look into this possible spam, and let us know what actions you take to resolve.” Statistics: 150 alerts in last 9 months (about 4 a week)

12. Situational awareness reports Alerts from our campus border flow analysis OCIS staff process alerts of suspicious activity daily (M-F). These alerts may be indicative of compromised server or personal computer, however, they may sometimes be the result of end activity, eg P2P file sharing, Skype, etc. The current alerts look for a variety of conditions, eg suspicious SMTP/DNS activity, connections to suspicious IP addresses as listed by REN-ISAC (Research and Education Network Info Sharing and Analysis Center), etc.

13. Situational awareness reports Example: “Our flow analysis tool is alerting on a possible suspicious activity Originating from This may be a sign of a compromise, infection, or user activities, eg peer to peer applications, etc. “ Include (in part): Network flows Why suspicious, eg connecting to known cc server, etc Statistics: 34 in last two months (about 4 a week)

14. Situational awareness reports Project HoneyPot Alerts OCIS staff receives alerts of email spam, dictionary web attacks, etc for UW System from the Project Honey Pot service (www.projecthoneypot.org). OCIS pays a small amount yearly for this subscription.

15. Situational awareness reports Example: 144.92.X.X (SPAM) - Sat, 26 Jan 2008 22:56:04 -0500 - DCC-MsgId: 426a2a78 5bfc2ebc e9c189b8 40c608fb - Subject: Armchair Vegas - From: "ClubVIP Casino." Statistics: 280 in last 20 months (about 3 a week)

16. Situational awareness reports REN-ISAC OCIS staff receive alerts of possible "bots" or otherwise compromised machines directly from REN-ISAC operations that their system may identify.

17. Situational awareness reports Example: The host(s) listed at the bottom of this message have been identified as likely bot infected. The host(s) were observed attempting to connect to a known botnet controller at 152.8.146.168 tcp port 5190. Please examine this machine for signs of break-in. IP Address Timestamp ---------------------------------------- 146.151.X.X 2006-02-12-17:54:47-UTC-5 Statistics: 125 in last 22 months (about 1 a week)

18. Situational awareness reports Shadowserver Foundation OCIS staff receive alerts for the University of Wisconsin- Madison from additional honeypots installed around the world and maintained by security volunteers running the Shadowserver Foundation (www.shadowserver.org) The types of reports that we may receive are listed at this url: http://www.shadowserver.org/wiki/pmwiki.php/Services/R eports

19. Situational awareness sources Example: Statistics: 118 reports in the last 10 months (about 3 a week)

20. Information Incident Reporting Policy http://www.cio.wisc.edu/policies UW-Madison employees, contractors and users of UW-Madison information resources must report incidents in which there is a reasonable belief that UW-Madison sensitive information may have been accessed by unauthorized persons. Reportable incidents include but are not limited to: intrusion by malware or other unauthorized access via the network into computer systems or devices, where it is reasonable to believe that sensitive information was accessed by unauthorized persons.

21. Information Incident Reporting Policy Sensitive data defined: Institutional Data that could, by itself or in combination with other such Data, be used for identity theft, fraud, or other such crimes. It includes Data defined as Restricted Data. Restricted Data includes information with Personal Identifying Information (PII) as specified in Wisconsin’s data Breach Notification Law (statute Section 134.98) Institutional Data whose public disclosure is restricted by law, contract, University policy, professional code, or practice within the applicable unit, discipline, or profession Etc

22. Information Incident Reporting Policy

23. Nessus self service scans Purpose: A convenient way to obtain a baseline scan of campus devices on the network without having to purchase and maintain Nessus software Location: https://www.cio.wisc.edu/security/scanning Statistics: Over 200 scans requested since January 2008

24. Nessus self service scans

25. Limitations: Scans done without local credentials Firewalls (host and network) need to be open Limited effectiveness with those using NAT Verbose reports

26. IBM AppScan self service scans Purpose: A convenient way to obtain a baseline scan of web servers without having to purchase and maintain Appscan software. Location: https://www.cio.wisc.edu/security/scanning Statistics: Over 100 scans requested since January 2008

27. IBM AppScan self service scans

28. Limitations: Scans done without credentials to web site, eg pubcookie, etc Firewalls (host and network) need to be open Verbose reports Crawling large sites may result in long scan times Load on web server Default form values used by Appscan may result in false negatives

29. Lockdown 2009! http://cio.wisc.edu/events/Lockdown

30. Questions?