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.
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? • Many computer intrusions happen because software is out of date • Sys admins and users can make more informed decisions about patches and threats
Where does info come from? Vulnerabilities & Patches: • Vendor bulletins & contacts • Microsoft, Sun, Cisco, Oracle, Apple, Linux • Mailing lists • email@example.com, Full Disclosure • Other reliable sources • CERT, ISS X-Force, iDefense, Last Stages of Delirium, Shmoo
Where? cont. New exploits in the wild & other incidents: • Mailing lists • firstname.lastname@example.org, email@example.com, FIRST, Shmoo • Contacts around campus • island.stanford.edu, Expert Partners, LNAs • Other reliable sources • DShield, ISS X-Force
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?
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?
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!
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)
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
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
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
How does it get written up? • Consistent format between alerts • Summary • Technical Details • Countermeasures • References
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
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
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?
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
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
Where do they end up? • http://securecomputing.stanford.edu/alert.html • Mailing lists: Expert Partners, LNAs, etc. • Newsgroups
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?
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!
For more information http://securecomputing.stanford.edu/alert.html http://www.precision-guesswork.com/metaweather.html