SQL Slammer Clean-up: Contacting CERTs
Last Updated: 2010-10-29 17:53:59 UTC
by Kevin Liston (Version: 1)
As you go through the process of individually-contacting abuse-contacts (http://isc.sans.edu/diary.html?storyid=9664) and work your way up the stream (http://isc.sans.edu/diary.html?storyid=9712) you may eventually end up the state/nation-level. This should only occur in cases where the ISP is unresponsive, or actually complicit in behavior. For something like slammer this shouldn't be the case, but for completeness I'd like to cover how to engage CERTs.
Each CERT is unique. They have varying levels of funding and organization, their missions are not consistent from one country to another, but they do have a couple of things in common. Most are clearing-houses for abuse-reporting. If your research into the owner and up-stream provider of an infected IP address isn't turning up working contacts, they can usually help identify the correct contacts and forward the report on for you. Also, they are each responsible to a specific constituency.
Before contacting a CERT it's important to study their mission and their constituency. You will not get good results if you report an IP address or an organization that is outside of their scope. Some CERTs do not actually accept abuse reports from individuals or organizations and only service other CERTs (e.g. Asia Pacific Computer Emergency Response Team-- apcert.org)
As an individual or organization directly reporting an incident to a CERT it's best to use their online reporting form. This assures that your report enters their work-flow and contains the information that they require. Sending an email in your own format runs the risk that it may be ignored. If you shotgun your report as an email to multiple organizations and CERTs it's almost guaranteed to be ignored by most or all of the recipients on your list. However, if what you have to report doesn't fit with their reporting-form and you think an email is necessary, they are quite fond of digital signatures.
Let's look at a couple of examples. For reporting slammer, your two most common countries are China and the United States. CNCERT has an easy web-form to report infections: http://www.cert.org.cn/english_web/ir.htm. There's a little captcha to prove that you're a human, you fill out a few fields, select "Virus, worm or trojan infection" from the incident type, paste your logs/packet dump in the description field, and ask that they system be taken off-line or cleaned. Be sure to record when you sent the report in your tracking spread-sheet and what kind of response you get.
US-CERT (http://www.us-cert.gov) has their own reporting forms, they break them down into: incident, phishing, and vulnerability. For something like slammer, you'd use the "Report an Incident" link: https://forms.us-cert.gov/report/ They collect some contact information, as well as more details about how the incident is impacting you (none to minimal in the case of slammer attacks,) what type of followup you require (none, contact or forward-- probably forward in this case.) They ask for the current status of the incident, since the slammer infection is still ongoing, you could use the "Occurring" status. They have a couple of fields to use to describe the incident, one of them is specifically for pasting logs-- use that.
Reporting to an organization such as a CERT is often an act of faith. You're not likely to get a quick, human response (not like when you submit something to us: http://isc.sans.edu/contact.html) but your efforts do have an impact. The attention that an IP address gets grows more and more reports come in from multiple organizations. This is why I've been soliciting you to make your own reports individually as opposed to a request of "send me all of your known SQL slammer infections."
we're quickly approaching the end of this exercise, so next week I'll post the results and go into more of the background of why I chose Slammer and how I organized the drill.
http://www.cert.org/csirts/national/ has a good list. Also, for Europe there's http://www.enisa.europa.eu/act/cert/background/inv
Also be aware that the top level government CERT may not be the best CERT to contact except as a last resort. For example, the UK has two state run CERTs, GovCertUK and the Centre for the Protection of National Infrastructure CSIRTUK (CPNI).
GovCertUK (http://www.govcertuk.gov.uk/reporting-an-incident.shtml) is based inside GCHQ - the direct UK equivalent of the NSA, whilst the CPNI (http://www.cpni.gov.uk/key.aspx) is based in the Security Service (MI5), kind of an internal version of the CIA. They're unlikely to be interested unless:
-The infection/problem is on a government network, or
-The problem is prejudicial to British interests, or
-The problem may cause damage to, or is on, critical national infrastructure.
Though if it's any of the above, they move *fast*.
Oct 29th 2010
1 decade ago
Thanks your for bringing up an important topic. Trying to find a suitable reporting point for network and information security incidents is a form of art at best and a nightmare at worst.
I would like to bring two related papers to your readers' attention.
1) You mentioned in your blog posting that each CSIRT are unique. We here at CERT-FI conducted a study in 2008 where we examined 11 European government-appointed CSIRTs in an effort to find good practices and fresh ideas for future development of CERT-FI. An English-language summary of that paper can be found at CERT-FI web site:
2) We constantly face the difficulty of matching information about the incident with their victims or other affected parties. To start with, the mere act of getting enough (or any) incident related information from those who happen to discover security breaches is nontrivial. And when we do get information we may find out that we don't know who the issue is affecting or how to reach those we can figure out.
I spent a fair amount of my leisure time last winter and spring writing a paper on the challenges the national CERTs face with the incident response coordination. CERT-FI was the chosen target for the study but some of the findings are bound to be common with all CSIRTs. This paper can be downloaded from here:
For instance, chapters 3.2 and 5.2 deal with the topic of trying to identify a responsible reporting point. Appendix II gives a simplified example on the method devised in the chapter 5.2.
Any comments on either of these papers would be welcome. Thanks!
Nov 3rd 2010
1 decade ago