Guidelines on securing public web servers

Abstract

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL's responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL's research, guidance, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.Step 5: Maintaining the secure configuration through application of appropriate patches and upgrades, security testing, monitoring of logs, and backups of data and OSStep 6: Using, publicizing, and protecting information and data in a careful and systemic mannerStep 7: Employing secure administration and maintenance processes (including server/application updating and log reviews)Step 8: Conducting initial and periodic vulnerability scans of each public Web server and supporting network infrastructure (e.g., firewalls, routers).The practices recommended in this document are designed to help mitigate the risks associated with public Web servers. They build on and assume the implementation of practices described in the NIST publications on system and network security listed in Appendix A.When addressing Web server security issues, it is an excellent idea to keep in mind the following general information security principles [Curt01 and Salt75]:Simplicity-Security mechanisms (and information systems in general) should be as simple as possible. Complexity is at the root of many security issues.Fail-Safe-If a failure occurs, the system should fail in a secure manner, i.e., security controls and settings remain in effect and are enforced. It is usually better to lose functionality rather than security.Complete Mediation-Rather than providing direct access to information, mediators that enforce access policy should be employed. Common examples of mediators include file system permissions, proxies, firewalls, and mail gateways.Open Design-System security should not depend on the secrecy of the implementation or its components. "Security through obscurity" is not reliable. Separation of Privilege-Functions,to the degree possible, should be separate and provide as much granularity as possible. The concept can apply to both systems and operators and users. In the case of systems, functions such as read, edit, write, and execute should be separate. In the case of system operators and users, roles should be as separate as possible. For example, if resources allow, the role of system administrator should be separate from that of the security administrator.Least Privilege-This prin...

Management of security policy configuration using a Semantic Threat Graph approach

“…Conforming to best practice provides confidence that a security policy is upheld. For example, the National Institute of Standards and Technology (NIST) provide a set of recommended guidelines for securing public Web servers [64], recommending that "all traffic between the Internet and Web server" should be controlled and that "all inbound traffic to the Web server except traffic which is required, such as TCP ports 80 (HTTP) and/or 443 (HTTPS)" should be denied.…”

“…. and is configured to perform the following" [64]. The RFC2119-style classification provides a basis with which to construct a concept hierarchy of best practice recommendations (firewall rules).…”

“…Best practice standards for network access control, including PCI-DSS [12] for systems that process credit card information, NIST for secure Webservers [64] and Internet RFCs for anti-bogon [35] have been encoded as Semantic Threat Graphs, providing a basis for firewall (iptables [28] and TCP-Wrapper [66]) configuration recommendations for known threats [22]. For the purposes of illustration in this paper the Semantic Threat Graph encoding of a fragment of NIST-800-41 [67], depicted in Table 1, is considered.…”

“…For example, bogon firewall rules [35,49,67] are best-practice protection against spoofing-threats for internal servers and end-user workstations, while NIST recommend multiple countermeasures over an n-tier network hosting a Web-server [64]. This knowledge-base is searchable-a suitable countermeasure can be found for a given threat-and provides the basis for autonomic security configuration.…”

An Approach to Security Policy Configuration Using Semantic Threat Graphs

“…For example, bogon firewall rules [11,12,13] are best-practice protection against spoofing-threats for internal servers and end-user workstations, while NIST recommend multiple countermeasures over an n-tier network hosting a Web-server [14]. This knowledge-base is searchable-a suitable countermeasure/policy can be found for a given threatand provides the basis for autonomic security configuration.…”