Advisory Management
William Sherman The company for which I work has a strong policy on computer security that requires all systems to have all known security vulnerabilities closed as soon as possible. This has led to the development of a simple, yet effective method for determining which vulnerabilities exist on which systems. The UNIX team at my company is responsible for about 60 data servers running different versions of the IBM AIX and HP-UX operating systems. To meet this requirement, we have developed a script that is run on all systems to check for these vulnerabilities. It requires a spreadsheet to be maintained manually, then exported and sent to each system. The script uses this spreadsheet as input to check each system. Once it is in place, the checks are automatic, specific to each version of each operating system. Since we only use AIX and HP-UX, those are the only items we capture. Other could be added easily. Information Gathering All of the data is gathered from the usual sources - CERT (www.cert.org), CIAC (ciac.llnl.gov), vendors (IBM, HP, TIS, ISS), and Usenet (comp.security, etc.). There is a poster available from SANS at www.sans.org that lists many other security sources, and I recommend that this source be reviewed. The individual bulletins are stored in a public mail folder accessible to UNIX, NT, and network administrators only. They were originally stored in an unrestricted folder until some enterprising contractors decided to see whether the "ping of death" really worked. It did. And amazingly, it pinged their contract as well. The security bulletins are gathered then summarized in a spreadsheet (see Table 1). The rows contain the date of the alert, alert number, and description, then operating system and version-specific fix numbers. One possible use of the date field is for comparison to release date of the operating system version. Most security problems fixed in prior releases are also fixed in releases shipped after the fix is in place. We do not do that, so security problems from 1995 will sometimes show up as problems in current releases. The alert information is useful as a reminder of what the problem is. We try to cut and paste from the actual alert, so they match. It is important that the column headers for the operating system and version are exactly equal to the names generated in the script. The script generates the operating system name and version using a mixture of uname(1) calls to keep it standardized. The format we have chosen is operating system, version, and release (uname; uname -v; uname -r). Since the spreadsheet is exported as a comma- or tab-separated file, it will make life a lot easier if the entries are identical to these calls. The column for fix numbers should not have hard line feeds inserted. Change the column heading to autowrap for prettiness. Hard line feeds will cause erroneous output when the file is exported. Multiple patches can be put into a single column. We also use some abbreviations in this column: ND = NO DATA (for this operating system and version on the alert), IP = In Progress (and no number assigned), and N/A = Not Applicable (to this operating system and version). Other abbreviations could be used as needed. Reviewing Threats New bulletins are reviewed for potential threat and put into the spreadsheet as soon as they are received. Each alert is reviewed at a weekly staff meeting to make sure all administrators are aware of the potential problem. This also reinforces the checking of daily and weekly system event reports. Systems are categorized according to exposure. Anything directly connected to the Internet gets patched immediately. Other systems are patched according to our Service Level Agreements (SLA) with each of the individual projects or departments. In our SLA, we specify that security patches can be applied with less than 24 hours notice, because security breaches can directly affect the data integrity of the system. Special attention is given to the system logs (syslogd) and other reporting mechanisms. Some security advisories suggest a change in the way reports are generated, such as checking for unusual usage of sendmail or failed rlogin attemps that might otherwise be overlooked. Security Reporting This report is one of many that are run for system verification. The frequency and detail of run is dictated by the exposure of the system. Checking for security advisories is done weekly, and copies of the report are sent to both the public mail folder and another UNIX system used for archiving these reports. We have worked with the internal auditing department to allow them access to the reports so they can check specific systems as required. This saves us a lot of time in supporting them and gives them the information they require. Internal auditing has worked closely with us in keeping upper management informed. This gives us grounds for requesting additional resources to resolve security-related problems. The actual script and related output are shown below in Listing 1 and Listing 2. Future Enhancements The biggest enhancement is having an automated method of extracting the information and updating our spreadsheet. While this data is easily applicable to a database, so far we have found it easiest to leave it in the spreadsheet form. We have also considered putting the data into a Web table that could be updated for specific users. This would allow a single source of data, but would also make it easier for potential crackers to spot holes. This report could also be modified to review other items, such as year 2000 compliance or package compatibility levels. We may do this, but now we tend toward keeping the support scripts simple and will probably create another table for those applications. Conclusion Computer security has a high profile within our company. This script has helped greatly in supporting our internal departments by providing organization and an automated mechanism for checking system vulnerabilities. By combining this tool and procedure with our other security tools and procedures, we hope to maintain the integrity of our computing environment. About the Author
Bill Sherman is a UNIX Consultant currently working in the electrical and telecommunications industries. His email is: bill.sherman@webmail.bellsouth.net
|