It is important to start with a configuration that is secure and hardens the Web server for its role on the Internet. Review the exhaustive hardening guide produced by the U.S. National Security Agency called Guide to the Secure Configuration and Administration of Microsoft Internet Information Services. Also evaluate your baseline configuration using the free Benchmark and Scoring Tools from the Center for Internet Security. Windows-based servers can also be tested against Microsoft's free Baseline Security Analyzer. Once you are satisfied with your baseline configuration it can be used to roll out additional servers.
Initial hardening and configuration is based solely on the facts known at the time of set up so you need to reassess your systems on a continuous basis to ensure that their security adapts and evolves to keep up with changes in technology and attack vectors. To make sure this happens, you need a lifecycle management process to ensure tasks are executed in an orderly and predictable manner and that none are forgotten or left incomplete. With well-defined policy guidelines you can also ensure that responses to problems are suitably covered.
You should develop and maintain a list of resources on security problems and software updates relevant to your system and application software. Establish a procedure for monitoring these information sources. Not all updates will be applicable to the configuration of your servers and to your security requirements, so you need to evaluate updates for applicability. Before installing any updates on your live servers, install them in an isolated test environment and run a series of trials.
Updates to live systems should always be done using a documented plan (which obviously includes a backup of each system), to ensure that you deploy configurations and updates consistently throughout your servers and that none are missed. It is good practice to use only an isolated network segment when propagating updates or to use something like SSH2 to provide secure access control and transmission. After making any changes to your servers' configuration or system files, create new cryptographic checksums or other integrity-checking baseline information. Maintain an archive of updates that you have evaluated and chosen to install so that you can install them on new servers before they are deployed.
Thankfully, there is software available to help you with the tasks of managing multiple servers. Windows Server 2003 supports Remote Installation Services, which lets you create and replicate server images and then roll them out remotely across a network, while the Microsoft System Center provides deployment and management tools to simplify managing groups of servers. HP provides the HP Systems Insight Manager for its ProLiant servers, and Red Hat Network allows administrators to manage and deploy configuration files, create system snapshots and manage the systems on their network. If you are running multiple servers on different Windows platforms, you may want to look at ScriptLogic's Service Explorer, which allows you to manage multiple services and tasks across multiple servers simultaneously.
Finally, lifecycle management means taking a long-term view and implementing proactive as well as reactive policies. For example, periodic vulnerability assessments will ensure that you remain secure (proactive) and assess whether your policies support quick incident response (reactive). The CIS Benchmark and Scoring Tools I mentioned earlier are kept up to date as new vulnerabilities are discovered so they can be used on a regular basis to monitor the effectiveness of your configuration.
About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.
This was first published in December 2005