NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS time lapses from the last full backup, requiring more processing time and storage than would an incremental backup. Generally, full backups are performed less frequently (weekly to monthly or when a significant change occurs), and incremental or differential backups are performed more frequently (daily to weekly). The frequency of backups will be determined by several factors: Volatility of information on the Web site • Static Web content (less frequent backups) • Dynamic Web content (more frequent backups) • E-commerce/e-government (very frequent backups) Volatility of configuring the Web server Amount of data to be backed up Backup device and media available Time available for dumping backup data Criticality of data Threat level faced by the Web server Effort required for data reconstruction without data backup Other data backup or redundancy features of the Web server (e.g., Redundant Array of Inexpensive Disks [RAID]). 9.2.2 Maintain a Test Web Server Most organizations will probably wish to maintain a test or development Web server. Ideally, this server should have hardware and software identical to the production or live Web server and be located on an internal network segment (intranet) where it can be fully protected by the organization’s perimeter network defenses. Although the cost of maintaining an additional Web server is not inconsequential, having a test Web server offers numerous advantages: It provides a platform to test new patches and service packs prior to application on the production Web server. It provides a development platform for the Webmaster and Web server administrator to develop and test new content and applications. It provides a platform to test configuration settings before applying them to production Web servers. Software critical for development and testing but that might represent an unacceptable security risk on the production server can be installed on the development server (e.g., software compliers, administrative tool kits, remote access software). The test Web server should be separate from the server that maintains an authoritative copy of the content on the production Web server (see Section 9.2.3). 9-7
GUIDELINES ON SECURING PUBLIC WEB SERVERS 9.2.3 Maintain an Authoritative Copy of Organizational Web Content All organizations should maintain an authoritative (i.e., verified and trusted) copy of their public Web sites on a host that is inaccessible to the Internet. This is a supplement to, but not replacement for, an appropriate backup policy (see Section 9.2.1). For simple, relatively static Web sites, this could be as simple as a copy of the Web site on a read-only medium (e.g., Compact Disc-Recordable [CD-R]). However, for most organizations, the authoritative copy of the Web site is maintained on a secure host. This host is usually located behind the organization’s firewall on the internal network and not on the DMZ (see Section 8.1.2). The purpose of the authoritative copy is to provide a means of restoring information on the public Web server if it is compromised as a result of an accident or malicious action. This authoritative copy of the Web site allows an organization to rapidly recover from Web site integrity breaches (e.g., defacement). To successfully accomplish the goal of providing and protecting an authoritative copy of the Web server content, the following requirements must be met: Protect authoritative copy from unauthorized access. • Use write-once media (appropriate for relatively static Web sites). • Locate the host with the authoritative copy behind a firewall, and ensure there is no outside access to the host. • Minimize users with authorized access to host. • Control user access in as granular a manner as possible. • Employ strong user authentication. • Employ appropriate logging and monitoring procedures. • Consider additional authoritative copies at different physical locations for further protection. Establish appropriate authoritative copy update procedures. • Update authoritative copy first (any testing on code should occur before updating the authoritative copy). • Establish policies and procedures for who can authorize updates, who can perform updates, when updates can occur, etc. Establish a process for copying authoritative copy to a production Web server. • Physically transfer data using secure physical media (e.g., encrypted and/or write-once media, such as CD-Rs). • Use a secure protocol (e.g., SSH) for network transfers. Include the procedures for restoring from the authoritative copy in the organizational incident response procedures (see Section 9.3). 9-8
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56: GUIDELINES ON SECURING PUBLIC WEB S
Page 105: GUIDELINES ON SECURING PUBLIC WEB S
show all

NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

Create successful ePaper yourself

Delete template?

Save as template?