The ICPSR Web Site and Security

"Is the ICPSR Web site secure?"

This question - in one form or another - crops up from time to time. Sometimes the question comes from a prospective depositor; sometimes from an ICPSR research submitting a grant application; sometimes from ICPSR's Council; etc.

The quick answer is that "Yes" but often the person asking the question would like a bit more information, of course. ICPSR doesn't face the same sort of threats and level of attacks as the more high-profile targets (banks, sites of people or organizations who are embroiled in controversy, government sites), but we do see regular, unsophisticated attacks on a regular basis. This post describes a few of the pro-active steps we take to ensure the site is working well for our members, partners, and other clients.

(1) Open Source software. Wherever practical we like to use open source software. Despite some reports that using open source is risky, our own experience is that using open-source software minimizes risk. The vast majority of security incidents that require action on our part (e.g., updating software) apply to proprietary vendor software from companies.

(2) SSH and the ssh port. Very few people at ICPSR have shell access to the Web server, and those that do must use ssh to connect. Unlike ftp or telnet where passwords (and sessions) pass in the clear, ssh presents an encrypted channel between the point of access (e.g., a desktop Mac) and the Web server. We also deploy ssh service on a non-standard TCP/IP port number to screen out the thousands and thousands of daily login attempts from the "script kiddies."

(3) Vulnerability scans. Like most computers at the University of Michigan, our central IT Security Services (ITSS) organization scans our Web server quarterly for common vulnerabilities. Unlike most computers, however, ITSS also scans us monthly using a more extensive list of vulnerabilities. Asking a third-party to audit the system is really, really valuable and helps identify issues that might not otherwise make it onto our radar screen.

(4) Network and system monitoring. Another third-party that helps us out is the Merit Network Operations Center (NOC). (Merit is the research and education network in the State of Michigan, and was one of three organizations that built the original Internet - the NSFnet.) The NOC monitors all of our systems 24 x 7 x 365, paging us within three minutes of any serious problem. While this doesn't necessarily prevent a problem such as a denial of service attack, it does bring it to our attention immediately so that we can take corrective action, day or night.

(5) Reviewing system and application logs. We use a rotating on-call schedule to field alerts and pages from the NOC. In addition to enjoying the thrill of carrying a pager, cell phone, laptop, and broadband wireless card, the on-call also has the responsibility for reviewing key system and application logs during his/her tour of duty. For example, the on-call inspects the nightly logwatch reports for all sorts of possible problems.

(6) Replica web site. ICPSR maintains a replica of its Web delivery infrastructure in one of the public computing and storage cloud to guard against an extended problem with the web site. Like NOC monitoring above, this does not prevent a security problem, but it does make it easier for us to recover from an attack against ICPSR or the University of Michigan.

(7) Backups and archival storage. Like almost any organization with important digital content, ICPSR employs standard tape backup strategies for its "working data." Our storage appliance writes several TBs of content to a multi-drive, tape library system in a separate building, and we then remove tapes from that system on a regular basis, placing them in a third location. Unlike most organizations (except for libraries and archives), we also move selected materials into archival storage. Items in archival storage are tested on a regular basis for integrity against their digital fingerprints, and are replicated many times for durability. Copies are stored in many different locations.

(8) SANS certification. We have found it useful to ensure that at least one member of the team is always up-to-date with his/her SANS certification. SANS is a widely recognized source for security training and certification, and it has often been helpful to have someone on the team with both the expertise and the credentials one receives from SANS.

(9) Network management, router filters and firewalls. Operating a data network has no strategic value to ICPSR, and therefore rather than operate one as amateurs (or misdirecting the resources to acquire the expertise in it), we contract with the University of Michigan's central IT organization to manage our network. They monitor it 24 x 7 x 365 for problems; make sure that the router and switch software is patched and current; and also maintain a series of router filters that act like a firewall, screening out unwanted traffic. For example, one router filter prevents anyone from outside connecting to the sqlnet port on our database server. (Even if one can reach the sqlnet port, a valid login and password is still required, of course.)

(10) Version control. One of the biggest risks to systems is oneself. To keep our systems safe from our own mistakes, we make extensive use of version control. Key system configuration files get checked into and out of RCS; Web site content and software goes into our CVS repository.