Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Query the IAO to determine if the site has a detailed process as part of its Configuration Management Plan or COOP to prevent the use of unsupported software and to provide a process to upgrade web server software. If the web server staff cannot provide a copy of the Configuration Management Plan or the COOP that addresses software replacement or upgrade, this is a finding.
Develop a Configuration Management Plan or a COOP to address a life cycle methodology approach to managing production web server software.
Even if the IR, with regard to the production web server is governed by an MOU or SLA, the majority of the elements listed in this check must still be addressed within those documents. Assurances will be provided by the application owners to the hosting administration. Assurance and any supporting documentation will be made available to an authorized reviewer. Ask the IAO, the SA, or the web administrator if an IR plan exists for the production web server being reviewed. If a plan exists, then determine if the plan contains the following elements: 1. The IR plan addresses specific requirements with respect to the data types on the server such as reporting requirements for the loss or compromise of public, private, or classified data. 2. The IR plan addresses policy and procedures that may be documented in the COOP that will contain specific procedures necessary to recover the server, the hosted sites, and any data that may have been lost. 3. The IR plan should name specific individuals with incident and response responsibilities. Assurance should be documented that these individuals have received IR training. 4. The IR plan addresses notification and coordination of incidents with regard to reporting chains such as security officers and management personnel. Other items to consider are as follows: Have any of the listed procedures actually been tested with regard to mock incidents, data recovery, and server/site recovery? If they were tested, are they then performed on a periodic basis? If an IR plan cannot be produced, or if the web administrative staff is not aware of the IR policies and procedures, this is a finding.
Establish and maintain a documented IR plan that addresses the IR procedures for the production web server.
All scripts and programs executing on a production web server must be tested and evaluated for security issues prior to being installed on the production server. A distinction is made between DoD web servers hosting web sites that are wholly under their control, such as a command that has written and developed a web application and then hosts that web application, and a web server hosting web sites where development is performed remotely and hosting is governed by a memorandum of understanding (MOU) and the service level agreement (SLA). It is not the responsibility of the SA or the web administrator to perform tests or security evaluations on scripts implemented on the production web server. It is the responsibility of the agency or vendors that developed the application to perform all testing and security evaluations. If the web server is owned by the activity that developed the web application, the activity is responsible for all testing and security evaluations. The activity will retain all proofs and documentation supporting this requirement. These proofs will be provided upon request to any individual authorized to review the web server. If the web server hosts web sites where the applications have been remotely authored and the hosting is governed by an MOU and/or the SLA, those remote organizations or vendors are responsible for all testing and security evaluations. In this case, such proofs supporting this requirement will be made available to the hosting activity for the purpose of this compliance check. These proofs will be provided upon request to any individual authorized to review the web server. The reviewer will ask to see all supporting proofs that are necessary to support this requirement. The reviewer may work with the IAO, the IAM, the SA, or the web administrator to determine a feasible sampling of programs and scripts in order to verify compliance with this requirement. If actual testing information is available indicating the method of testing, the individuals responsible for testing, and the individuals approving the test outcomes, the reviewer will note their existence as a part of the supporting proofs. The actual testing of scripts and programs is outside of the scope of this guidance and is governed by the Application Security and Development STIG.
Ensure proof of testing and security assurance is available. Ensure that CGI documentation is available.
The reviewer will verify that an appropriate training program is in place and that web server personnel are either certified or in the process of certification. The following elements will be reviewed: 1. A training program is in place that addresses DoD publication 8570.01M with respect to either the IAT or the IAM certification of the web server staff at the appropriate certification level, according to job roles and responsibilities. 2. Web server staff will either be DoD IAT- or IAM- certified according to their roles or be in the process of achieving DoD IA certification. 3. Training records are maintained. 4. DoD IA certification must remain active. 5. Web server staff will be CE certified. CE certification should be specific to operating systems, server hosts, etc. If web server staff administers multiple technologies, current guidance suggests that CE certification should be achieved for all supported technology. At a minimum, certification should be achieved for the technology he or she spends the most time supporting. 6. The certification program may be instructor-led, given through a CBT, or be blended. It may be vendor-specific or a component-developed equivalent certification. Testing or proof of knowledge and skill is required. It is highly suggested that, with respect to web server administration, emphasis be given to the expected functional duties of the web server staff. This emphasis should concentrate in areas that may include, but are not limited to: • Security threat and mitigation techniques. • Securing critical files and processes. • Back up and recovery techniques. • OS and the web server software administration. • OS and web server hardening techniques. • The application of access controls. • Disaster recovery. • Incident response and analysis. If elements listed above are not in place or the web server staff is not certified or is in the process of certification, this is a finding.
Assign certified staff to respond to operational and content issues.
The intent of this check is to provide awareness to the hosting agency of all CGI and program scripts installed on the web server in support of hosted content. It is not the responsibility of the hosting agency to document the CGI and program scripts. It is the responsibility of the agency owning the web application or web site to provide this information to the hosting agency. Documentation will include the language used, the purpose of the program, and an IA certification. This documentation will be provided to the IAO. If a COTS product is installed containing CGI, it will be documented by the owner of the hosted information. If a manifest is available for the COTS CGI or it is feasible to generate a manifest listing the CGI associated with the COTS product, it will be provided to the hosting agency. There will be no penalty at this time for failure to provide a list of COTS associated CGI, but it will be a requirement to provide IA assurance for the COTS product. The potential direction of this requirement may be to scan against the installation of unauthorized programs and scripts. The reviewer will ask to see an example of a documented program from the web server. If the site cannot produce documentation that shows that it is maintaining documentation of interactive programs, this is a finding.
Establish a process for ensuring all CGI programs used on the web server are documented. Documentation will include the language used, the program’s purpose, and the program’s IA certification. This documentation will be provided to the IAO.
It is not the responsibility of the hosting agency to document the data sensitivity level and security category of the hosted information. It is the responsibility of the information owner to provide this documentation to the IAO of the hosting agency. If this documentation is not in the possession of the IAO, this is a finding.
Acquire the data sensitivity level and security category of information published on a production web site.
If an MOU or an SLA exists between a hosting agency and the information owner, those documents will address the requirement presented in this check. If the hosting agency is responsible for CM, it will provide the proof. If the information owner is responsible for CM, it will provide assurance and supporting information to the hosting agency. The reviewer will have access to this documentation and any supporting materials. The SA and or the web administrator should be in possession of or have access to the most recent Configuration Management Policy as developed by the organization. They should also be able to demonstrate policy compliance. Review the risk assessment, security plan, and any supplements necessary to verify that these procedures are documented. Required elements of CM: 1. An indication of who approves the changes to both administrative configuration changes and the software installed on the production web server. 2. A process that documents and audits web server configuration and web server software changes, approvals, and disapprovals. 3. A process or policy that addresses procedures with regard to what may or may not be configured, changed, or implemented. If a Change Management Policy does not exist, or compliance cannot be demonstrated, this is a finding.
Documented CM policies and procedures will be made available to the IAO, the SA, or the web administrator.
It is assumed that once a server has been configured for production, an image is captured that can serve as an initial baseline for that server in addition to records detailing the initial configuration settings. An automated tool or process that can capture a web server’s configuration settings, take checksums of web server and OS software and their associated essential files, create a baseline from these actions that can fully restore the web server, and notify personnel of baseline changes is highly preferred. This would satisfy the requirements associated with this check. If a web server can be fully restored from backups or other means without the need for manually configuring the web server, this requirement is considered mitigated and this is not a finding. If a web server can be restored from backups or other means but requires manually configuring the web server, then those configuration settings must be documented. If those configuration settings are not documented, this is a finding. If it is not possible to ascertain the ability to restore a web server from backups or other media without the necessity to manually configure the web server, the reviewer will request documentation on web server configuration changes that have taken place since the initial image baseline and documented settings of the server was created. CM documentation associated with changes to the web server will satisfy this requirement. However, the activity should attempt to consolidate this information into its recovery procedures. If the configurable settings for the web server are incorporated into recovery documentation, this is not a finding. If the reviewer is not provided with CM documentation when requested, this is a finding. If the web server has not changed since its initial baseline, this is not a finding.
Establish and maintain a configuration baseline for the production web server.
The intent of this control is to manage software changes for web sites on a production web server and to have in place mechanisms that prevent unauthorized and uncontrolled implementation of application code and scripts. This control does not address change management from the perspective of code changes and reviews that take place by a development team at the development level. Only code and scripts that physically reside or will reside on the production web server are affected by this check. After a development team has gone through a change management process for application code, and approved code changes to a production application or script, what change management process is in place to actually deliver that code and implement it on a production web server? A process will exist to manage change from the point where code has been approved and is awaiting implementation to the point where it is actually implemented on the production web server. A fully automated change management solution that places approved code in an access controlled interim location, scans it for viruses, date and time stamps records of receipt, and maintains a record of an authorized ID or service that initiated the change is preferable and would meet the requirements of this check. A manual or semi-automated process incorporating the majority of the following elements would also meet the intent of this check. Such processes are as follows: 1. The code is placed in an interim location and scanned for viruses. 2. An audit entry, manual or automated, exists to date and time stamp the receipt of the code changes. This entry will also include the authorized ID, web service or program or individual, associated with the change process. 3. Access control mechanisms are placed on the interim location so that only authorized personnel, programs, or services may access or write to or read from that location. 4. The delivery of the code to the interim location is through a secured channel. 5. The delivery of the code from the interim location to the production web server is through a secure channel. 6. Direct implementation of code on the production web server by developers or code authors is prohibited. Only SAs, web administrators, or authorized and secured services or programs may implement the code on the production web server. If change management to the production web server is governed by an MOU or an SLA, the majority of the elements listed above must still be addressed within those documents. Assurances will be provided by the application owners to the hosting administration. These assurances will be made available to an authorized reviewer. If a majority of the elements listed above are not a part of the change management process, this is a finding. NOTE: The future direction of this requirement is to require that all elements must be satisfied and not just a majority.
Ensure that a process is in place to control change on a production web site.
Recovery of a web server or site can be as relatively simple as renewing a license to as complex an issue as rebuilding a server or site from scratch. Within the COOP for the Information System (IS) under review, a detailed plan should have been developed that completely spells out the procedures necessary to affect recovery. These procedures and check lists should be as complete as possible in order to achieve organizational goals with respect to availability, integrity, and confidentiality. Ask the SA or the web master to produce the COOP and specific recovery procedures for the IS (i.e., web server, web site, etc.) under review. The hosting activity that administers the web server is ultimately responsible for its recovery procedures. These procedures should include all necessary steps and information required to recover the OS, the web server software (i.e., IIS, Apache, etc.), and all supporting software and utilities. The activity that owns the hosted application or web site is ultimately responsible for its recovery unless a MOU or an SLA exists that indicates an alternate responsible party. Regardless of responsibility, the procedures necessary to recover a web site will be provided to the hosting agency and available for review. Key elements that should be addressed in recovery procedures: 1. A copy of supporting MOU or SLA, if applicable. 2. Contact information for recovery personnel including their roles and responsibilities. 3. Contact information for vendor-specific support and assistance. 4. Information about vendor license and vendor support agreements. 5. Information about specific IS components and their inter-relationships that are within the scope of the recovery. 6. The readily accessible location of current vendor-specific documentation that is necessary to the recovery effort. 7. Procedural check-off lists that appear to be logically ordered and complete. 8. Procedures for the re-verification or testing of the functionality of security controls after a recovery has been affected. Ask the SA or the web administrator if these procedures have ever been tested in an appropriate test environment and how frequently the process is reviewed and re-tested. If the listed elements are not addressed in the recovery procedures, this is a finding.
Ensure that current recovery procedures exist and are included as a part of the COOP.
The intent of this check is to determine the awareness of deployed mobile code by the hosting agency, the SA, or the web administrator. The agency that owns the web application, which has been developed in accordance with the Application Security and Development STIG, will provide the hosting agency with information regarding the use of mobile code technology, including the type of mobile code used and any threat mitigations or configurations necessary for its deployment that require the SA’s or the web administrator’s involvement. Information regarding the use of mobile code deployment, including any responsibilities of the hosting agency, may be included with a MOU or the SLA. A list of deployed mobile code by server should be accessible in the event of threats against a specific technology. If the hosting agency does not deploy mobile code technology, the finding is Not Applicable. The SA or web administrator should only need to have access to information by server of deployed mobile code and, if necessary, any responsibilities they may have with regard to configurations, threat mitigations, etc., as indicated by the MOU or the SLA. If mobile code technology is deployed and the SA or the web administrator does not have access to deployment information, this is a finding.
Ensure the SA and the web administrator is aware of deployed mobile code.
When the web server software is going to be changed, updated, or patched, or when the web server software configurable settings are going to be changed, a process must exist to document, test, and receive approval for the change prior to its implementation on the production web server. This check focuses on the review, testing, documentation, and approval aspects of the change management process. Ask the SA, or a member of the Change Control Board (CCB), to show proof that a documented Change Management (CM) process exists to test changes to a production web server, prior to implementation. Key requirements of the process should include the following: 1. A documented security impact assessment. 2. The names of those individuals who completed the security impact assessment. 3. A plan developed to test the change. 4. The names of those individuals who tested the change. These individuals should not be the same individuals who designed the test plan. 5. An indication of what was being tested. 6. A description of how the test was performed. 7. A summation of the testing results. 8. An indication of testing success or failure. 9. An indication of any residual IA concerns. 10. The names of the approving authority that reviewed and accepted the testing results, including their commentary and/or their concerns. The provided proofs of the CM process should include the CM policy and those documents required by the policy. The policy should substantially address the elements listed above. If proof that the CM process does not substantially include the elements listed above, particularly with regard to testing, this is a finding.
Include testing documentation in the CM process.
The intent of this check is to verify that audit logs generated by web server software (e.g., IIS, Apache, etc.) are retained according to DoDI 8500.2 requirements. This requirement should be a part of either the hosting agency’s SOP or a local audit policy. Logging element requirements for the web server are covered in technical checks. Since web server software relies on the OS to process log events, the OS STIGS will govern all methodologies and policies related to access, handling and storage, transit, and processing. This check only addresses minimum retention periods for web server logs. An MOU or an SLA may require more restrictive retention periods such as those that deal with access to Sources and Methods Intelligence (SAMI) data as defined in DoDI 8500.2. This check does not affect requirements as may be specified in a MOU or an SLA between a hosting agency and an information owner as long as minimum retention periods are achieved. Auditable events and policies, such as those that may be specified by the Application Security and Development STIG, are governed by that STIG. Event logs and policies that may be required by other STIGs will still be governed by those STIGs. The reviewer will work with the IAO, the SA, or the web administrator to verify that audit logs, as generated by the web server software, are retained according to the following requirement: 1. SAMI access will be retained for a minimum of 5 years. 2. Other access will be retained for a period of 1 year. If the reviewer cannot ascertain the retention period for web server logs, this is a finding.
Archive web server access logs for at least 1 year. In the case of SAMI information, the requirement is 5 years.
The organization or activity that sponsors the web site will have web content responsibility. These persons will ensure that all information is kept current and that information placed on the web server is reviewed and approved by the Public Affairs Officer (PAO). This organization will provide assurance to the hosting agency that this requirement has been satisfied. The organization or activity that owns the web site will develop local policies in accordance with the DoD Web Site Administration Policies & Procedures, dated 25 November 1998 (updated 11 January 2002), available at: http://www.defenselink.mil/webmasters/policy/dod_web_policy_12071998_with_amendments_and_corrections.html. The following elements will be included in that policy: 1. All organizational personnel should receive training appropriate to distinguish between public and non-public information, but specific training is given to content approving authority. 2. Periodic re-review of posted information. 3. Procedures and contact information that address the discovery and subsequent removal of published information that is considered to be in violation of current law, policy, directive, or is outdated. A copy of this policy will be provided to the hosting agency for the purpose of the site review associated with this check. It is not the responsibility of the hosting agency to review or re-review posted information. If, however, the hosting agency ever notices policy violations or the posting of questionable content, they will take appropriate action. If review assurance for publicly posted information is not available, or if a policy containing the listed elements is not available, this is a finding.
Acquire review assurance and local posting policies for publicly published information.