|
|
| |
|
|
|
|
Origin: TechRepublic (http://www.techrepublic.com)
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 (see Figure 1).
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. 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. Here is a partial list of vendors that sell software security testing tools and services for development and integration environments:
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:
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). Here is a partial list of managed vulnerability assessment vendors that offer those services:
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. 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:
Bottom line
|
 |
|
 |
|
|
Copyright 2002© EHTO All rights reserved EHTO is not responsible for the contents of external websites it links to. Mail suggestions to: webmaster@ehto.org |
