Chapter 25. Mining the Data Monster

IN THIS CHAPTER

·        Information Overload

·        How Much Security Do You Need?

·        General Sources

·        Mailing Lists

·        Usenet Newsgroups

·        Vendor Security Mailing Lists, Patch Depositories, and Resources

Computer security is a process, not a product. The process is constant, and not following it can prove disastrous. Generally speaking, the security process goes something like this:

1.       After configuring your system as securely as possible with help from resources discussed in this chapter, you, or some other party, discover a vulnerability.

2.       An exploit for that vulnerability becomes public knowledge.

3.       Your system's vendor responds, typically with a patch or upgrade.

4.       By staying on top of alerts posted by vendors and security organizations, you learn of the exploit, assess its potential impact on your organization, and, if appropriate, you download the fix, test it, and install it.

With luck, the fix works, without negative effects, and the process begins anew as you await the discovery of the next vulnerability. The key is this is an iterative process, and an important part of the process is staying on top of the information available, without suffering information overload.

Information Overload

This chapter offers a laundry list of mailing lists, Web sites, and FTP archives that house security information. That's great. However, if you subscribe to any security mailing list, you'll immediately discover that list members are only slightly more courteous than Usenet users. These folks argue like school children, and they'll do it on your time.

This dissension is a major problem. Your mailbox will be filled with, say, 100 messages daily when only 12 of them have valuable information. The rest will consist of arguments, "me-too"s, and, sadly, spam.

Note

Nothing is worse than an argument between competing vendors. These arguments sometimes continue for days with participants making allegations of slander, libel, and so on. In 99% of cases, such saber rattling ends with a whimper (instead of a bang). Meanwhile, list members are bombarded with nonsense. What makes things even worse is that participants often change the subject line or vary their posting addresses, making it difficult for you to filter out the noise.

This might not seem like a serious problem, but it is. If you run a heterogeneous network, you need to subscribe to several lists. Because the average list generates about 30 messages a day, you might end up receiving between 150 and 300 messages daily.

Here are some suggestions to help you out:

·        Compartmentalize. Before joining a slew of mailing lists, prepare your system to compartmentalize the output. Set up an old box expressly for receiving mail. Allot one email address for each mailing list you join. For example, create accounts ntsec, sunsec, and hpuxsec to receive mail related to NT security, Sun security, and HP-UX security. This will at least separate the material by operating system or subject. (If you don't have a permanent network connection, you can still do this by establishing Web-based mailing addresses. Many companies provide free email accounts to the public. The downside with that, of course, is that many mailing lists will block domains such as hotmail.com, altavista.net, and dejanews.com because these domains are often used for spamming).

·        Subscribe to digests or moderated groups only. Most mailing lists offer a digested or moderated version of their list. These versions generally have a lesser noise-to-signal ratio. In other words, irrelevant posts and messages are edited out prior to distribution. You therefore receive more relevant and pertinent information.

It might be worth your time to automate at least the cursory analysis of advisories and mailing list messages. For example, if you maintain a network that runs three or four platforms, the amount of security mail you receive each day will be more than you can humanly read. With the use of Perl scripts, you can develop a primitive but effective method of mining data automatically. It works like this:

1.       As suggested previously, structure your directory to reflect the names of various operating systems (/aix, /linux, and so on) and various security issues (such as /denial_of_ service).

2.       When a mail message arrives, it's examined by subject line and the first six lines of the body. If an operating system name appears in those lines, the mail is redirected to the appropriate directory.

3.       Once a day, a Perl script traverses those directories, scanning for original posts. (In other words, all "Re:" posts are discarded from the list.)

4.       The resulting messages are printed.

This process ensures that we see every original advisory. The obvious problem with this approach, however, is that often, meaningful discussion appears in follow-up posts. Most moderated mailing lists enable you to search for a particular "thread" of interest. This way, your time is focused on the few items of importance to you, rather than on several issues that do not affect you.

How Much Security Do You Need?

Do you really need all that information from all those lists? Probably. Most vendors wait until strategically favorable moments to distribute patches on hard media. Therefore, by the time you get a CD-ROM with patches, your system can be 30–100 patches behind. In the interim, your system isn't safe.

Additionally, if you don't keep up with developments on at least a weekly basis, bringing your network up to date might prove to be an overwhelming task.

Note

Another irritating factor is that some vendors aren't in any hurry to publicly acknowledge flaws in their software. Microsoft is sometimes guilty of this, denying problems until proof becomes so widespread that they no longer have plausible deniability. Even then, the information often only becomes available in knowledge base articles and such.

Just as a car manufacturer cannot be held responsible if the owner has not maintained brakes and tires, a computer vendor cannot be responsible for a system that is not configured securely with up-to-date patches. The bottom line is that it's your responsibility to chase down security information. If your network gets cracked, it's you (and not your vendor) who shoulders the blame. You must keep yourself informed on recent developments.

The remainder of this chapter identifies key sources of up-to-date security information. I strongly suggest that you assign someone in your organization to track such information.

General Sources

The following sources have both up-to-the-minute information and legacy information.

The Computer Emergency Response Team (CERT)

Computer Emergency Response Team (CERT) Coordination Center

Software Engineering Institute

Carnegie-Mellon University

Pittsburgh, PA 15213-3890

URL: http://www.cert.org

The Computer Emergency Response Team (CERT) was established in 1988, following the Morris Worm incident. Since then, CERT has issued hundreds of security advisories and has responded to more than 200,000 reports of Internet break-ins.

CERT not only issues advisories whenever a new security vulnerability surfaces, but it also

·        Remains on call 24 hours a day to provide vital technical advice to those who have suffered a break in

·        Uses its Web site to provide valuable security information, both new and old (including papers from the early 1980s)

·        Publishes an annual report that can give you great insight into security statistics

There was a time when CERT did not publish information on a hole (a vulnerability) until after a fix has been developed. Opinion on this stance varied. Some felt it was counterproductive to advertise an exploit until it was fixed. On the other side of the fence were those who believed that, by the time the "white hat" community became aware of a vulnerability, the "black hat" cracking community was well aware of it and probably had been circulating information about it through their channels for some time. By not publishing the information right away, CERT was keeping the ethical hacking community unaware and vulnerable. In October 2000, CERT compromised by adopting a policy whereby it will issue an alert 45 days (in most cases) after its initial report, regardless of vendor action. Complete details on CERT's disclosure policy can be found on its Web site at http://www.cert.org/faq/vuldisclosurepolicy.html. CERT advisories generally contain location URLs for patches and vendor-initiated information. From these sites, you can download code or other tools that will help proof your system against the vulnerability.

CERT is also a good starting place to check for older vulnerabilities. The database goes back to 1988.

Note

A bit of trivia: The first CERT advisory was issued in December 1988. It concerned a weakness in FTPD.

There are several sources where you can obtain CERT advisories, including

·        The CERT mailing list. The CERT mailing list distributes CERT advisories and bulletins to members. To subscribe, send email to majordomo@cert.org and include "subscribe cert-advisory" in the body of the message. For more details about signing up, see http://www.cert.org/contact_cert/certmaillist.html.

·        The CERT Web site. If you don't want to clog your email directory with advisories, you can still obtain them from the CERT Web site. To do so, point your browser to http://www.cert.org/nav/alerts.html.

·        The CERT FTP site. If you don't have access to a browser, you can retrieve CERT advisories via FTP at ftp://ftp.cert.org/pub/.

The U.S. Department of Energy Computer Incident Advisory Capability

Computer Incident Advisory Capability (CIAC)

Computer Security Technology Center

Lawrence Livermore National Laboratory

7000 East Ave

P.O. Box 808

Livermore, CA 94550

URL: http://www.ciac.org/ciac

Computer Incident Advisory Capability (CIAC) was established in 1989. CIAC maintains a database of security-related material intended primarily for the U.S. Department of Energy. However, most information (and most tools) housed at CIAC is available to the public.

The CIAC site is an excellent information source. Here are some CIAC resources available to you:

·        CIAC virus database. This database contains specifications and descriptions for thousands of viruses. Listings include the virus filenames, aliases, types, features, disk locations, and effects. Often, additional information is available, including identifying information, checksums, and methods of detection and elimination.

·        CIAC security bulletins. CIAC bulletins are very much like CERT advisories. They describe particular vulnerabilities and possible solutions. CIAC has a search engine, as well, so you can rake through past bulletins, looking for interesting information.

·        CIAC security documents. CIAC has an interesting and ever-growing collection of security documents. Some are how-to in nature (for example, how to secure X Window), whereas others are informational (such as lists of security information links). Most are available in both plain text and PDF formats.

·        CIAC tools. CIAC has links to excellent security tools, most of which are free. There are tools that support DOS/Windows 9x, NT/2000, UNIX, and Macintosh. Some are free only to government agencies and their contractors.

CIAC has a searchable archive of advisories and bulletins at http://www.ciac.org/cgi-bin/index/bulletins.

Important information provided by CIAC to the public includes the following:

·        Defense Data Network advisories

·        CERT advisories

·        NASA advisories

·        A computer security journal by Chris McDonald

The National Institute of Standards and Technology Computer Security Resource Clearinghouse

Computer Security Resource Clearinghouse (CSRC)

National Institute of Standards and Technology (NIST)

Gaithersburg, MD 20899-0001

URL: http://csrc.nist.gov/

The NIST CSRC Web site offers a sizable list of publications, tools, pointers, organizations, and support services. In particular, the following resources are extremely helpful:

·        NIST Information Technology Laboratory (ITL) computer security bulletins. Bulletins from ITL cover various topics of current interest. Although ITL documents seldom deal with specific vulnerabilities, they do apprise readers of the latest developments in security technology.

·        CSRC drafts. CSRC drafts record important security research being conducted at NIST and elsewhere. These documents can help you define security plans and policy. (A sample title is User Guide for Developing and Evaluating Security Plans for Unclassified Federal Automated Information Systems. This document explains ways to develop and evaluate security plans.) In particular, CSRC has a multitude of documents that deal with security policy.

·        The CSRC search engine. CRSC provides a search engine that links information from a wide range of agencies and resources.

The CSRC advisory page has links to other valuable references including the Federal Computer Incident Response Capability (FedCIRC), CERT, the National Infrastructure Protection Center (NIPC),and the Forum of Incident Response and Security Teams (FIRST). These sources provide up-to-the-minute warnings about various vulnerabilities.

You can retrieve FedCIRC advisories (without visiting CSRC) by pointing your browser to http://www2.fedcirc.gov/alerts/advisories_2001.html.

The BUGTRAQ Archives

The BUGTRAQ archives contain all messages sent to the BUGTRAQ mailing list. The majority of these messages describe holes in the UNIX operating system. The site is of particular interest because it features a search mechanism that enables you to search based on platform (Sun, Linux, Microsoft) viruses, IDSs, advisories, and other topics.

The BUGTRAQ list is an excellent resource because it isn't inundated with irrelevant information. The majority of posts are short and informative. Chris Chasin, the founder of BUGTRAQ, describes the list as follows:

This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vulnerabilities. It is about defining, recognizing, and preventing use of security holes and risks.

BUGTRAQ is probably the Internet's most valuable resource for online reporting of UNIX-based vulnerabilities. There are more than 20 different mailing lists that focus on specific platforms and security issues including forensics, security basics, VPN's, mobile code, and others. Visit it at http://www.securityfocus.com.

The Forum of Incident Response and Security Teams (FIRST)

FIRST is a coalition of many organizations, both public and private, that work to circulate Internet security information. Some FIRST members are

·        DoE Computer Incident Advisory Capability (CIAC)

·        NASA Automated Systems Incident Response Capability

·        Purdue University Computer Emergency Response Team

·        Stanford University Security Team

·        IBM Emergency Response Service

·        Australian Computer Emergency Response Team

FIRST exercises no centralized control. All members of the organization share information, but no one exercises control over any of the other components. FIRST maintains a list of links to all FIRST member teams with Web servers. Check out FIRST at http://www.first.org/team-info/.

Mailing Lists

Table send an email to identifies key security mailing lists. The majority of these lists issue up-to-the-minute advisories.

For a thorough compilation of mailing lists, you can also go to http://www.securityfocus.com. Select mailing lists from their main page. You will see about 20 lists. To see even more, click, "other lists" or go directly to it by going to http://www.securityfocus.com/focus/home/menu.html?fm=8,23,0&action=unfold and explore the lists available by category.

Usenet Newsgroups

You can also occasionally collect interesting information that doesn't appear elsewhere from Usenet security groups. Table 25.2 outlines some newsgroups that discuss security holes. Some newsgroups such as alt.2600 are included so that the reader can get an idea of how the hacker community shares, debates, and brags. The newsgroups are not all intended for everyday reading, but are interesting to visit once in a while. One final note: Newsgroups come and go, and activity might decrease over time. Make use of a newsgroup search engine such as DejaNews to find newsgroups that are active and relevant to you.

Vendor Security Mailing Lists, Patch Depositories, and Resources

Finally, this section identifies vendor sites, patch archives, and lists that house important security information.

Silicon Graphics Security Headquarters

Silicon Graphics, Inc.

2011 N. Shoreline Blvd.

Mountain View, CA 94043

URL: http://www.sgi.com/support/security/

The Silicon Graphics Security Headquarters provides the following services to the public:

·        SGI security advisories. SGI advisories provide up-to-the-minute information on vulnerabilities in the IRIX operating system. These advisories are available at http://www.sgi.com/support/security/advisories.html.

·        SGI security patches. SGI provides a patch archive. This is a good place to find solutions to older vulnerabilities. SGI patches are located at http://www.sgi.com/support/security/patches.html.

·        Q's toolbox of programs. This is a collection of security-related programs that can help shore up your SGI system's security. (These include scanning tools, logging utilities, and even access control list tools.) Get those programs at http://www.sgi.com/support/security/toolbox.html.

·        A site with several FAQs, which would be of interest not only to security managers but also to administrators and developers, is http://www-viz.tamu.edu/~sgi-faq/faq/html-1/. A sample tip that can be found here is what to do when you've forgotten the root password.

The Sun Security Bulletin Archive

Sun Microsystems, Inc.

901 San Antonio Road

Palo Alto, CA 94303 USA

Sun Microsystems provides up-to-date security bulletins about many of its products. These bulletins are available on the SunSolve server at http://sunsolve.sun.com/pub-cgi/show.pl?target=security/sec.

The Xforce Vulnerability Database

This site, http://xforce.iss.net, maintains an excellent vulnerability database. It is searchable by the name of the vulnerability, or by system platform. The site also has a Security Library with links to dozens of other sites, presentations, and PDF documents for ISS products.

The National Institutes of Health

The Computer Security Information page at the National Institutes of Health (NIH) is a link page. It has pointers to online magazines, advisories, associations, organizations, and other Web pages of interest in security. Check out the NIH page at http://www.alw.nih.gov/Security/security.html. This is a big site. You might do better examining the expanded index as opposed to the front page. That index is located at http://www.alw.nih.gov/Security/tcontents.html.

Eugene Spafford's Security Hotlist

Eugene Spafford's site can be summed up in five words: the ultimate security resource page. Of the hundreds of pages devoted to security, this is the most comprehensive collection of links available. In contrast to many link pages whose links expire, these links remain current. Check it out online at http://www.cerias.purdue.edu/coast/hotlist/.

SANS Institute

The SANS Institute offers free subscriptions to newsletters that do a lot of the data mining for you. SANS pulls news of critical security news from several of the sources mentioned previously (CERT, NIPC, bugtraq, and so on) as well as vendor sources that were not mentioned. SANS also puts together three digests:

·        Security Alert Consensus (SAC)—weekly

·        SANS NewsBites—weekly

·        SANS Windows Security Newsletter—monthly.

One that is particularly noteworthy is the SAC. When subscribing from the SANS Web site, you can specify which platforms you are interested in. This enables you to "personalize" your newsletter and limit the "noise" you might otherwise have to sift through. Currently, SANS collects news from 72 sources so you only need to read one. Sign up at http://www.sans.org/sansnews.

Summary

Your key to success is timely access to relevant information. Too much information, and you might not pay enough attention to an important issue that gets lost in the noise. So, before you go and subscribe to every list you find, keep in mind that there is a fair bit of redundancy and overlap in what many of them cover. Look through the lists'archives and see which lists suit you—which go into the level of detail you are comfortable with, and pay attention to issues that are relevant to your situation. This will be time well spent because the window between vulnerability announcements is becoming shorter and shorter.