CIOs and many other executives are looking into ways to make their enterprises' network-based applications safe for mission-critical business operations. As the "Sapphire" worm proved, enterprises face critical security issues that include Web servers. CIOs should evolve their security strategies for Internet-exposed services by following Gartner's guidelines.
Gartner's Recommended Web Security Hierarchy
Like any other area of information security, Web server security represents a risk-management exercise. Not every enterprise can afford to - or must - reach the ultimate level of security. Enterprises making simple use of their Web servers for mainly outbound marketing should implement fewer security controls than those using Web servers as entry points for e-business and other inbound services. The visibility and corporate culture of an enterprise also defines how much security should be put into Web servers. However, Gartner believes that all enterprises should take some basic steps to achieve a due diligence level to live up to the trust of customers and business partners.
Gartner has defined a layered approach to securing Internet-exposed Web servers. Gartner's recommended levels of security follow:
Level 1. All Web servers should be protected by a simple firewall that limits the ports and services the server exposes to the Internet and which monitors the state of connections to the server. The spread of worms and viruses would be greatly limited if firewalls in front of Web servers block them.
Level 2. The operating system under each Web server should be configured according to common security checklists, and vendor-specific tools should be used to validate the configuration. Security processes should be established that ensure all security patches are tested and promptly applied to all Internet-exposed Web servers. All Web applications should receive some form of security review before going into production.
Level 3. Network-based intrusion detection sensors should be deployed on the network segment hosting the Web servers. That will provide alarms if the servers come under attack, but defined processes are required to ensure that follow-up actions are taken.
Level 4. Installing host-based intrusion detection system (IDS) software on Web servers requires more operational expense, but can provide detailed indication of attacks against high-value servers. Before deploying such software, an enterprise must ensure that its processes support keeping IDS software operational on Web servers that may not be under the control of the security group.
Level 5a. Policy enforcement software acts as a layer between the Web server operating system and all applications. The products prevent hackers from subverting vulnerable applications to take control of the operating system. This approach carries the same operational cost of installing host-based IDS software and may be much less transparent to applications - providing a higher level of protection while incurring higher operational costs.
Level 5b. Deploying application-specific firewalls as proxy servers that focus on HTTP (and future protocols such as Simple Object Access Protocol, or SOAP) in front of Web servers can prevent the vast majority of attacks without requiring software to be installed on every server. However, this approach requires the addition of proxy servers that are powerful enough to minimize performance degradation of the Web site, and may require complex integration into load-balancing, content-switching and Secure Sockets Layer acceleration architectures.
Level 6. The most secure approach to Internet-exposed Web servers is to deploy only those that are nearly invulnerable. By running Web servers on trusted operating systems, or using appliances that are based on trusted operating systems, enterprises can achieve the highest level of security, but at a very high cost of ownership. Stringent processes must be established to ensure that all Web servers run the secure operating system software. All system administrators must be trained on the trusted software. Many applications, particularly new releases, may not run correctly on trusted operating systems, and integration costs will be significantly higher than other approaches.
Enterprises Must Broaden Their Approaches
Although those guidelines remain valid, improvements in Microsoft's Internet Information Server (IIS) Web server and increased hacker attention to Microsoft's SQL Server and other software products mean that enterprises must broaden their approaches to securing Internet-exposed applications and servers. Application security requires a "cradle to grave" approach, beginning with the requirements analysis and preliminary design phases. However, most enterprises can't start with a blank slate - they must begin by securing what has been deployed.
Buy the Most Secure Products
The best way to keep the IT infrastructure secure is to build it with secure products. If enterprises demand more secure products, vendors will build them. For example, in the Web server area, the problems caused by the "Code Red" and "Nimda" attacks drove enterprises to place enormous pressure on Microsoft to improve the quality of its software. Market competition is a wonderful thing - by forcing the largest software vendor to emphasize security, other software vendors are also driven to improve their products.
As of November 2002, Gartner considers the IIS Web server (with all patches installed and configured to eliminate unneeded services) to be roughly equivalent in security level to competing Web server software. If an enterprise has equal skill in administering IIS and Apache or iPlanet Web servers, it will spend about the same number of hours per week, per Web server, maintaining the security level.
That does not apply when SQL Server or Microsoft Data Access Components database connectivity is used as part of Internet-exposed Web servers. A stream of vulnerabilities are being exposed in this area in the Windows environment. The "Sapphire" worm illustrates the increased level of risk when exposing SQL Server to Internet connectivity. Thus, the security track record of each application should be a key selection criterion.
Build the Most Secure Applications
Many Internet-exposed applications include customized software. When vendors are used to develop applications, enterprises should require evidence that security has been considered during the development process. Enterprises also should require vendors to provide the output of security testing tools or evidence of external security reviews. For applications that are developed in-house, enterprises should plan to include security during the requirements analysis and high-level design phases. Therefore, enterprise security organizations must be more proactive and have the security skills necessary to contribute to application design efforts while meeting project deadlines. Gartner estimates that less than 20 percent of Global 5,000 enterprises have the internal security staff levels and expertise necessary to effectively drive the internal development of software to higher security levels.
If enterprises can't fit security into the early life cycle of software development, application-level security testing should be required, at a minimum, for all internally developed applications prior to their use in Internet-exposed product environments.
Install Everything Right
The current generation of software products rarely installs securely out of the box. Although Microsoft is known for violating the first law of security - "deny all that has not been explicitly allowed" - most Unix-based products haven't been much better. Microsoft has raised the bar in this area by focusing on "secure by default" in most new products. In addition, vendors and organizations, such as the Center for Internet Security, have developed thorough checklists to provide guidance to system administrators in secure-default configurations of Web servers and underlying operating systems. Web sites that provide security configuration checklists are:
- Apache - httpd.apache.org/docs/misc/security_tips.html
- Center for Internet Security - www.cisecurity.org
- Microsoft - www.microsoft.com/technet/itsolutions/security/tools/tools.asp
- Sun Microsystems - www.sun.com/security/blueprints
Web servers should have at least one firewall between them and the Internet. The firewall should limit the exposure of the Web servers to the minimum set of protocols that are required to meet business needs. In most cases, a Web server that allows Internet connections should also have a firewall between it and the internal, trusted network.
Continually Scan and Patch Software
The phrase "software engineering" will someday no longer be an oxymoron, and software products will fail no more often than highway bridges. Until that elusive "someday" arrives, enterprises must assume that software will become vulnerable as soon as they turn their backs to it.
Many enterprises pay consulting firms to perform penetration testing on a quarterly basis, or they run their own monthly scans. Those scans are insufficient when Web servers are changed on a weekly or daily basis. Gartner recommends that enterprises augment yearly or quarterly in-depth penetration testing with weekly automated vulnerability scanning (with a goal of daily scanning).
Enterprises should ensure that internal processes for configuration and patch management include a review of vendor vulnerability and patch alerts for applicability and criticality. In addition, critical patches should be moved to the top of the IT administration work queue for testing and deployment. Gartner believes that security patch management should follow processes similar to overall configuration management.
"Look Before You Leap"
Enterprises shouldn't get too comfortable with their security levels, even if they have followed the above guidelines, because software vendors are always ready to announce the latest versions of their products, which will be full of new features that they believe you can't live without. Because security is the current "hot topic," many of the new features will be advertised as making the latest versions "the most secure products ever produced."
However, new software usually has more vulnerabilities than old software. Therefore, Gartner advises that enterprise security organizations don't adopt major software product updates until at least six months after their initial release (generally the first major service pack), or longer for vendors that have poor track records in security. Where operational needs dictate migration earlier than that, host-based IDSs should be used to rapidly detect attacks that take advantage of new vulnerabilities.
Add Security Where Necessary
Gartner believes that its guidelines constitute a best practice set to meet the due diligence security level for most enterprises. However, some enterprises in regulated environments, or where senior management or corporate culture dictate higher levels of security, should add other levels of security:
- Harden the operating system;
- Use application-level firewalls;
- Install host-based IDS or prevention software.
Summary of Gartner's Tactical Guidelines
- Purchase only the most secure products when building an IT infrastructure.
- Build security into customized applications.
- Ensure that products and applications are installed correctly.
- Continually scan for and patch software security vulnerabilities.
- Don't purchase software updates until at least six months after initial release.
- Add additional security layers when able and where necessary.
Bottom Line
Through 2008, 90 percent of successful hacker attacks will exploit well-known software vulnerabilities (0.8 probability). Enterprises that follow Gartner's guidelines will eliminate much of the exposure of the vulnerabilities to external and internal attacks. However, Murphy's Law still rules security - "What can go wrong, will go wrong; what can't go wrong, will also go wrong." Therefore, enterprises should develop internal or external incident response processes to mitigate the effects of successful attacks.