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
Work with the IAM to determine if there is an automated patch distribution system for security related patches for all services. Review each technology to determine if there is a fully functional automated patch distribution solution. This does not negate the need for patch testing prior to installation. Patches should not be automatically pushed to devices and servers or both, prior to testing in a non-production environment. Each asset and the DMZ system as a whole must support and utilize an automated patch capability.
Configure the DMZ systems to utilize an automated patch capability for all services within the DoD DMZ.
Review the DMZ Concept of Operations (CONOPS) policy and procedures along with system device configuration and implementation documentation to ensure reporting requirements include providing NetOps alert and log data to the appropriate local CNDSP, and Combatant Command or Agency NOC, in near real-time without significant delay so the alert or log data does not become non-actionable. NOTE: Transmission in near real-time means the data is transmitted as it is generated or shortly thereafter. The data is not queued. NOTE: This finding can be reduced to a CAT III in the event the component is polled regularly and often so the alert or log data does not become non-actionable.
Provide NetOps alert and log data, for all components within or supporting a NIPRNet DoD DMZ, to the appropriate local CNDSP and COCOM, or Agency NOC in near real-time without significant delay such that the alert or log data does not become non-actionable.
Review the DMZ architecture to ensure all Internet facing service traffic traverses the IAPs and no other Internet connection. The intent is to avoid multiple entrance points and to ensure all traffic is visible to the sensor grid and the security devices located in the Special Purpose Extension.
Design the DoD DMZ so all Internet facing application and service traffic flows traverse the existing DoD ISR/IAPs at the Internet boundary. There will be no alternate connections. All data traffic must flow through DoD-controlled and maintained Internet boundaries.
Review the DMZ CONOPS to determine if policy and procedures are in place to test and apply critical and maintenance level security related patches to all devices in the DMZ within the time frame identified in the sites configuration management plan. Devices must be in compliance with all USCYBERCOM issued IAVM notices and any critical emerging threats and vulnerabilities. Ensure all appropriate mitigations are in place until all patches can be applied to systems.
Test and apply all critical and maintenance level security related patches within the time period as specified in the sites configuration management plan (as part of the CONOPS).
1. Unrestricted web servers and Restricted web servers can either be on separate physical servers from each other or they can be on separate virtualized servers using a type 1 hypervisor. Note: Logical separation via virtualization can be achieved; however, virtualization is only permissible when type 1 hypervisors are used. A type 1 hypervisor sits on bare metal server hardware and hosts guest operating systems. Virtualized systems follow the same rules of non-virtualized systems. Example: Unrestricted web server OSs and Restricted web server OSs can either be on separate physical servers or they can be on separate virtual servers using a type 1 hypervisor (logical separation). 2. Unrestricted web servers and Restricted web servers must be on separate logical or physical servers from Private web servers, Application servers, or Database servers. Note: Database servers, if used, housing Private data will not be located in the DoD DMZ Extension. 3. If Application and Database servers have been separated by service type into Unrestricted, Restricted, and Private servers (permitted but not required in Increment 1 Phase 1), they must be on separate logical or physical servers from each other by server type (App or DB) and by service type (U/R/P). Refer to the DoD DMZ Technology Overview and DoD DMZ FAQs for details and definitions of the three data types.
Configure the DMZ systems to maintain logical or physical OS separation by server type (App or DB) and by service type (U/R/P).
Review the DMZ backup policy to ensure systems are backed-up via an automated process, in accordance with the defined backup and recovery process identified in the DoD DMZ CONOPS.
Employ an automated backup schema to include full/incremental/differential backups as appropriate to meet disaster recovery requirements as defined by the DoD DMZ CONOPS.
Review the DMZ backup policy to ensure storage medium is capable of 5 year retention and retrieval and a support device capable of reading the data must be maintained.
Utilize appropriate media capable of guaranteeing file integrity for a minimum of 5 years for all system backups, and maintain a support device capable of reading the data.
Review the backup policy to ensure permissions and procedures are in place to validate personnel for approval to access or request access to backups and archives.
Only those personnel with granted appropriate levels of access can request or gain access to backups and archives.
Review the backup process and procedures to ensure an automated means of backup media verification is present.
Verify correct backup media has been written to and restored from, via an automated process.
Review a sampling of backup data to ensure sensitivity labeling is present to differentiate between data types. Review the CONOPS to ensure a process is documented for labeling of backup data.
Include processes in the CONOPs to correctly label removable storage media based on sensitivity level and content (unrestricted vs. restricted data).
Review the Disaster Recovery Plan for the DoD DMZ to ensure it is in compliance with minimum restoration guidelines as established by the DMZ CONOPS. The DRP must include business recovery plans, system and facility contingency plans, and plan acceptance.
Develop a DRP providing for the resumption of mission, or business essential functions, within the specified period of time as defined by DMZ CONOPS. A DRP must include business recovery plans, system and facility contingency plans, and plan acceptance.
Review the Disaster Recovery or Continuity of Operations Plan (COOP) to ensure process and procedures are in place for backing up and storing critical infrastructure device operating systems and configurations.
Develop documented procedures ensuring all critical systems, to include infrastructure devices such as routers and their associated configuration files, are backed up and copies of the operating system and other critical software are stored in a fire rated container or otherwise not collocated with the operational equipment or software.
Review the Continuity of Operations Plan (COOP) to ensure processes and procedures are in place for back-up and storage of data in accordance with the frequency as defined in the DoD DMZ CONOPS.
Document procedures ensuring data backup is performed in accordance with the DMZ CONOPS, and recovery media is stored off-site at a location affording protection of the data in accordance the CONOPS and data availability requirements and confidentiality level.
Review the logging server documentation to ensure procedures are in place to bring the system back on-line in case of shutdown or failure.
Document procedures to restore the log program efficiently if the program goes down, or must be shut down.
Review the SIM documentation to ensure event or alert data is sent in near real time and is not using a manual process such as FTP. The devices must automatically send SIM data with no manual intervention. Near real time refers to the delay introduced, by automated data processing or network transmission, between the occurrence of an event and the use of the processed data.
Configure the SIM to send and process inbound event and/or alert data in near real time with no manual intervention required.
Review the vendor documentation to ensure the SIM uses an industry standard database, not a “homegrown” database, which has been evaluated against a NIAP/NSA approved Protection Profile.
Employ a SIM using an industry standard database.
Review the SIM backup procedures to ensure encryption is utilized for restricted and unrestricted backup of SIM data. The backup procedures must ensure there is segmentation between restricted and unrestricted data types. File and database access restrictions will also be in place to reduce the potential of exposure of the restricted data.
Encrypt all data on the SIM stored database backup, using FIPS 140-2 validated cryptography, so the unrestricted database cannot restore the restricted database when utilizing the same media.
Review the back-up procedures and the on-line configuration to ensure the SIM data is stored for a minimum of 30 days online and 1 year off-line and readily available in accordance with the DoD DMZ CONOPS.
Configure the SIM to maintain 30 days worth of security event data online and 1 year offline, readily available to the analyst.
Review the RWP vendor documentation and the National Institute of Standards and Technology (NIST) Validation website (http://csrc.nist.gov/cryptval/140-1/1401val.htm) to determine if the encryption components have been validated against FIPS 140-2.
Utilize only reverse web proxy cryptographic components that are FIPS 140-2 validated.
Review the SIM server/system documentation to ensure procedures are in place to efficiently bring the system back on-line in case of shutdown or failure. The application security event logs must continue if the SIM goes down. The recovery process and times must be in accordance with the DoD DMZ CONOPS.
Document and implement the procedures to restore the SIM service if the program/system fails or must be shut down.
Review the management network architecture to determine if local console access, KVM, or terminal services are available for local management network, for failover purposes. Review the management architecture against the most current version and release of the Network Infrastructure STIGs.
Provide local management for devices within a DMZ via console and/or KVM or terminal server, in case of local management network failure.
Review the DMZ CONOPS and associated policy to determine if systems within the DMZ are required to request certificates only from a DoD-approved CA. A list of DoD-approved CAs can be obtained from the following URL: http://iase.disa.mil/pki/eca/index.html. Self-signing certificates are not authorized.
Require DMZ system components to request PKI certificates from a DoD-approved CA. Self signed certificates are not authorized on DMZ components.
Review the DMZ CONOPS and associated policy to determine if systems within the DMZ are required to support and utilize DoD approved PKI CRL policy. DoD OCSP must be supported by DMZ components and devices and is the first choice for CRL validation.
Configure DMZ system components to support and utilize DoD-approved PKI CRL or DoD OCSP policy.
Review the DMZ reporting procedures to ensure denied traffic and application transactions, at any component within the DMZ, are reported to the local log aggregation/SIM capability in real time.
Configure the DMZ system to report denied traffic and application transactions to the appropriate local log aggregation/SIM capability in real time, generated automatically, not as a manual process or batch process.
Verify the devices providing IA for different DMZ services include, but are not limited to email security gateway, reverse web proxy, DNS proxy, and FTP proxy are implemented at a minimum on logical, separate VLANs, or on physically different network segments. The separation is for the IA controls on a per application basis (e.g., the RWP must be logically separated from the email security gateway (EMSG)). This does not imply a load balancer function cannot reside on a Web Application Firewall. Infrastructure devices such as firewalls and IDS/IPS are not required to be separate as their functionality is to monitor all traffic, not application specific traffic types.
Design the DMZ architecture so logical network separation is maintained between devices performing IA functions for different IA services such as, Simple Mail Transfer Protocol (SMTP) and Hypertext Transfer Protocol (HTTP). This requirement is for singular IA function devices, not infrastructure devices such as firewalls and IDS/IPS
Review the DoD DMZ accreditation documentation to ensure all components comprising the DMZ and the network architecture are in compliance with the DoD NIPRNet DMZ Functional Requirements document and the DoD DMZ Engineering Plan (may be obtained from the Defense Knowledge Online (DKO) web portal). The CC/S/A/FA will develop a CONOPS in accordance with the DMZ Engineering Plan and should contain at a minimum, backup and recovery policies, configuration management plan, complete DMZ system and device details, architecture diagrams and traffic flows, operational policies, procedures, and responsibilities, and Network Operations (NetOps) tasks.
Develop a DoD DMZ CONOPS for any CC/S/A/FA DoD DMZ implementation. The CONOPS will be developed and maintained for each DoD DMZ instantiation which contains, at a minimum, backup and recovery policies, configuration management plan, system details, operational policies and procedures, architecture, and NetOps tasks.
Review the management interfaces on the infrastructure devices to ensure they have an interface dedicated to the management network. Ensure IP forwarding is not allowed (disabled) on the interface OR ensure it has an access list that only permits the management interface to communicate with the management network.
Configure each device within the DoD DMZ to utilize a dedicated interface for management functions only. There will be no other role associated with the management interface.
Review the infrastructure devices to ensure all management traffic is encrypted using FIPS 140-2 validated cryptography. Ensure clear text traffic services such as telnet and FTP are not enabled for the management interfaces. If the device cannot support the use of encryption for certain types of management traffic to the management server, this must be documented and approved.
Encrypt management traffic within a DMZ using FIPS 140-2 validated cryptography, for example, Transport Layer Security (TLS) v1, Secure Shell (SSH), etc., which are configured in accordance with the Network Infrastructure STIGs.
Review the ACLs on the boundary infrastructure devices such as routers and firewalls, or both, against the DMZ CONOPS and system documentation to ensure operational necessity of ports, protocols, and services is still accurate. The system documentation should have the operational statements to confirm current need for services permitted. The DMZ architecture will deny access to unnecessary or non-documented services.
Configure the DMZ architecture, and more specifically, the IA devices, to deny all inbound and outbound services except those specifically implemented or permitted based on documented operational necessity.
Review a sampling of system documentation to ensure the devices within the DMZ infrastructure are IPv6 capable. Review against the most current version of the Network Infrastructure and Backbone Transport STIGs, as well as the DoD Milestone Objective 3 (MO3) guidance, for additional IPv6 requirements.
Employ only IPv6 capable DMZ components.
Review a sampling of DMZ IA systems to ensure if they use a signature detection capability, (for example, a content checking mechanism), they are configured to update signatures at least daily, from a trusted source as approved by the IAM.
Update signatures at least daily for IA system components using signatures for detection.
1. U/R: Unrestricted web servers and Restricted web servers must be on separate logical or physical networks from each other, from the server to the DMZ firewall. Verify Restricted and Unrestricted servers are installed on separate VLANs or separate physical switches. 2. U/R and P: Unrestricted web servers and Restricted web servers must be on separate logical or physical networks from Private web servers, Application servers, or Database servers, if used, from the server to the DMZ firewall. Verify U/R servers are on separate VLANs or use physically separate switches from Private servers. Database servers, if used, housing private data will not logically reside in the DoD DMZ. 3. If Application and Database servers have been separated by service type into Unrestricted, Restricted, and Private servers (permitted but not required in Increment 1 Phase 1), they must be on separate logical or physical networks from each other by server type (Application or Database) and by service type (U/R/P). If implemented, verify that App-U, App-R, App-P, DB-U, DB-R and DB-P are all on separate VLANs or physically separate switching infrastructure from the server to the DMZ firewall. Refer to the DoD DMZ Technology Overview and DoD DMZ Engineering Plan for details and definitions of the three data types.
Configure the DoD DMZ systems to maintain logical or physical network separation between Unrestricted, Restricted, and Private servers as well as Web, Application, and Database servers.
Verify any device (e.g., RWP) terminating encrypted traffic for a private application does not also provide any service to Restricted or Unrestricted applications and services. Verify upstream switch, routers, and firewalls, block the private termination device from Internet access.
Configure the devices terminating encrypted traffic for private applications/services, so they do not also provide any service for restricted or unrestricted applications. The private termination device must not be reachable from the Internet.
Review the DMZ architecture to determine if a perimeter firewall, or separate firewall, configured in accordance with the Firewall STIGs, is in place and operational between the DMZ, Internet, and NIPRNet. This is a separate requirement from the General Business LAN firewall requirement in the Network Infrastructure STIGs. The Firewall STIG details the deep packet inspection requirement for firewalls.
Connect the DoD DMZ to the Internet and NIPRNet via peering, or completely dedicated perimeter, in-line firewall that performs deep packet inspection.
Review the DoD DMZ architecture to ensure there is a separate, dedicated management network for all privileged level device access and all IA related traffic flows.
Engineer the management network so all security related traffic, privileged level access to devices, etc., will traverse a dedicated management network.
Review the DMZ architecture to ensure all http/https traffic flows through a reverse web proxy and all http/https connections are brokered by the RWP. The RWP will employ, at a minimum, logical separation between Unrestricted data and Restricted data with separate VLANs at the subnets.
Employ a RWP as part of the DMZ architecture and require all HTTP/HTTPS connections to be brokered by the RWP.
Review the RWP vendor documentation to ensure the RWP supports the use of TLSv1 and SSLv3.
Ensure the reverse web proxy supports the use of TLSv1 and SSLv3.
Review the DMZ architecture to ensure a SIM is located within the DMZ to capture and process security relevant event data.
Deploy a SIM within the DoD DMZ providing real-time analysis of security alerts generated by DoD DMZ network hardware and applications.
Review the DMZ architecture to ensure a syslog server in deployed and operational within the management network to send log data from DMZ devices.
Deploy a syslog server within the DoD DMZ management network architecture.