Transcript How does it get written up?

Writing Security Alerts
tbird
Last modified 3/26/2016 8:16 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 protected], 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
• [email protected],
[email protected], 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!
40
35
30
25
# of
20
Alerts
15
10
5
Win
Solaris
Other
Oracle
Cisco
0
For more information
http://securecomputing.stanford.edu/alert.
html
http://www.precisionguesswork.com/metaweather.html