1 / 29

Writing Security Alerts

Writing Security Alerts. tbird Last modified 11/4/2014 11:20 AM. 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?. Why?.

philip-avila
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related