writing security alerts n.
Skip this Video
Loading SlideShow in 5 Seconds..
Writing Security Alerts PowerPoint Presentation
Download Presentation
Writing Security Alerts

Loading in 2 Seconds...

play fullscreen
1 / 29

Writing Security Alerts - PowerPoint PPT Presentation

Download Presentation
Writing Security Alerts
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Writing Security Alerts tbird Last modified 11/4/2014 11:20 AM

  2. Agenda • Why? • Where does this stuff come from? • What’s relevant to Stanford? • What’s important enough to bother with? • How does it get written up? • What do I do with it?

  3. Why? • Many computer intrusions happen because software is out of date • Sys admins and users can make more informed decisions about patches and threats

  4. Where does info come from? Vulnerabilities & Patches: • Vendor bulletins & contacts • Microsoft, Sun, Cisco, Oracle, Apple, Linux • Mailing lists • bugtraq@securityfocus.com, Full Disclosure • Other reliable sources • CERT, ISS X-Force, iDefense, Last Stages of Delirium, Shmoo

  5. Where? cont. New exploits in the wild & other incidents: • Mailing lists • incidents@securityfocus.com, intrusions@incidents.org, FIRST, Shmoo • Contacts around campus • island.stanford.edu, Expert Partners, LNAs • Other reliable sources • DShield, ISS X-Force

  6. How much information? • A few hundred email messages a day, depending on activity – much higher during major incidents, like RPC attacks • Most aren’t significant within Stanford environment – significant means “in use by enough people to merit a major threat if patch is not installed, or if attack is not mitigated” • What’s enough?

  7. What’s relevant to Stanford? • Operating systems: Microsoft Windows 2000 & XP, Macintosh OS X, Solaris 7-9, RedHat & Debian Linux, Cisco IOS • Applications: Internet Explorer, Outlook, Office, MS SQL Server, IIS, sendmail, OpenSSH, Oracle, AFS, Kerberos, Apache, OpenSSL • Others?

  8. What gets written up? • My goal: to distribute information on the sorts of things I’d be willing to get paged at 3am about • i.e.. only send an alert when something is an immediate threat, or requires immediate action • implies that alerts ought to include recommendations for action!

  9. What gets written up? cont. Vulnerabilities & patches: • Issue exists in default install of OS or widely used application (applies to lots of people) • Issue allows remote exploitation, or local exploitation for systems with lots of local users (ie. cluster machines)

  10. What gets written up? cont. • Vulnerability can be triggered with no action by user, or little action • RPC attacks • vulns in Web browsers that can be triggered via pop-ups • Vulnerabilities for which there are exploits in active circulation

  11. What gets written up? cont. Active attacks • Issues that are impacting Stanford and/or the rest of the Internet • Issues about which the security team is getting lots of questions • Issues that can be easily avoided by updating software or AV signatures

  12. Ah, but… • Almost all based on information collected from other sources – very little hands-on • Consolidate data, reconcile conflicts between sources, simplify for action by system admins and end users, tailor to Stanford environment

  13. How does it get written up? • Consistent format between alerts • Summary • Technical Details • Countermeasures • References

  14. Summary • “End user” language • Who’s affected: which operating system or application, which version • What’s the threat • What do you do (including URLs if appropriate) • Basis of email distribution

  15. Technical Details • Where’s the vulnerability • Why does the problem exist • How can it be exploited • For an attack or exploit, what sort of damage does it do • Any forensics: logs or other evidence of exploitation

  16. Countermeasures • Patches or software updates that mitigate threat – direct links to downloads by versions etc. • Workarounds if available and practical, to reduce risk from vulnerability or attack • System recovery – if an attack happens, what do I do?

  17. A Note on Patch Testing • We’re not set up to do much yet • Test Windows and OS X patches with the Leland and AFS applications • Working on getting more formalized testing in place as part of host security management initiative

  18. References • Vendor alerts • Third-party confirmation • CERT advisories, reports from research firms like ISS and iDefense • Enough information for a motivated reader to reconstruct everything in the alert

  19. Where do they end up? • http://securecomputing.stanford.edu/alert.html • Mailing lists: Expert Partners, LNAs, etc. • Newsgroups

  20. What do I do with it? • Do you use the affected system in the summary? • Are you responsible for your own machines? Other people’s?

  21. What’s it look like so far? • “Security alert process” in place since December 2002 • We’ve missed some! • We’d like to think that the RPC attacks of August & September were not typical… • Total: 61 in 13 months – so much for 1-2 per month!

  22. For more information http://securecomputing.stanford.edu/alert.html http://www.precision-guesswork.com/metaweather.html