NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
GUIDELINES ON SECURING PUBLIC WEB SERVERS<br />
6. <strong>Securing</strong> <strong>Web</strong> C<strong>on</strong>tent<br />
The two main comp<strong>on</strong>ents of <strong>Web</strong> security are the security of the underlying server applicati<strong>on</strong> and OS,<br />
and the security of the actual c<strong>on</strong>tent. Of these, the security of the c<strong>on</strong>tent is often overlooked.<br />
Maintaining effective c<strong>on</strong>tent security itself has two comp<strong>on</strong>ents. The more obvious is not placing any<br />
proprietary, classified, or other sensitive informati<strong>on</strong> <strong>on</strong> a publicly accessible <strong>Web</strong> server, unless other<br />
steps have been taken to protect the informati<strong>on</strong> via user authenticati<strong>on</strong> and encrypti<strong>on</strong> (see Secti<strong>on</strong> 7).<br />
The less obvious comp<strong>on</strong>ent of c<strong>on</strong>tent security is avoiding compromises caused by the way particular<br />
types of c<strong>on</strong>tent are processed <strong>on</strong> a server. As organizati<strong>on</strong>s have gotten better at protecting and<br />
hardening their network perimeters, OSs, and <strong>Web</strong> servers, attackers have increasingly turned to<br />
exploiting vulnerabilities in <strong>Web</strong> applicati<strong>on</strong>s and the way informati<strong>on</strong> is processed <strong>on</strong> <strong>Web</strong> servers.<br />
These applicati<strong>on</strong> layer attacks exploit the interactive elements of <strong>Web</strong> sites.<br />
6.1 Publishing Informati<strong>on</strong> <strong>on</strong> <strong>Public</strong> <strong>Web</strong> Sites<br />
Too often, little thought is given to the security implicati<strong>on</strong>s of the c<strong>on</strong>tent placed <strong>on</strong> the <strong>Web</strong> site. Many<br />
organizati<strong>on</strong>s do not have a <strong>Web</strong> publishing process or policy that determines what type of informati<strong>on</strong> to<br />
publish openly, what informati<strong>on</strong> to publish with restricted access, and what informati<strong>on</strong> should be<br />
omitted from any publicly accessible repository. This is troublesome because <strong>Web</strong> sites are often <strong>on</strong>e of<br />
the first places that malicious entities search for valuable informati<strong>on</strong>. For example, attackers often read<br />
the c<strong>on</strong>tents of a target organizati<strong>on</strong>’s <strong>Web</strong> site to gather intelligence before any attacks [Scam01]. Also,<br />
attackers can take advantage of c<strong>on</strong>tent available <strong>on</strong> a <strong>Web</strong> site to craft a social engineering attack or to<br />
use individuals’ identifying informati<strong>on</strong> in identity theft [FTC06].<br />
Absent compelling reas<strong>on</strong>s, a public <strong>Web</strong> site should not c<strong>on</strong>tain the following informati<strong>on</strong>:<br />
Classified records<br />
Internal pers<strong>on</strong>nel rules and procedures<br />
Sensitive or proprietary informati<strong>on</strong><br />
Pers<strong>on</strong>al informati<strong>on</strong> about an organizati<strong>on</strong>’s pers<strong>on</strong>nel or users 30<br />
• Home addresses and teleph<strong>on</strong>e numbers<br />
• Uniquely identifying informati<strong>on</strong>, particularly SSNs<br />
• Detailed biographical material (that could be employed for social engineering)<br />
• Staff family members<br />
Teleph<strong>on</strong>e numbers, e-mail addresses, 31 or general listings of staff unless necessary to fulfill<br />
organizati<strong>on</strong>al requirements<br />
30<br />
31<br />
For Federal agencies, this would include all items covered by the Privacy Act of 1974<br />
(http://www.usdoj.gov/04foia/privstat.htm). This encompasses pers<strong>on</strong>ally identifiable informati<strong>on</strong> (PII), which is<br />
informati<strong>on</strong> that can be used to uniquely identify, locate, or c<strong>on</strong>tact an individual.<br />
When an email address must be published <strong>on</strong> a <strong>Web</strong> site, c<strong>on</strong>sider the use of generic email addresses or aliases (e.g.,<br />
webmaster@mydomain.gov as opposed to jane_doe@mydomain.gov). There are two reas<strong>on</strong>s to do this. One, published<br />
6-1