SECURITY TECHNICAL IMPLEMENTATION GUIDE
ON
ENCLAVE SECURITY
Version 1, Release 1
30 March 2001
DISA
FIELD SECURITY OPERATIONS
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
ii
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TABLE OF CONTENTS
1. INTRODUCTION ......................................................................................................................1
1.1 Background .........................................................................................................................1
1.2 Definitions...........................................................................................................................1
1.3 Writing Conventions ...........................................................................................................3
1.4 STIG Distribution ...............................................................................................................3
1.5 Document Revisions ...........................................................................................................4
1.6 INFOCON ...........................................................................................................................5
2. ENCLAVE SECURITY GUIDANCE .......................................................................................7
2.1 Traditional Security ............................................................................................................7
2.2 Enclave Perimeter Security .................................................................................................7
2.2.1 Enclave Perimeter Network Intrusion Detection System (IDS) ...............................8
2.2.2 Router Access Controls ............................................................................................8
2.2.3 Enclave Firewall .......................................................................................................9
2.2.4 Virtual Private Network (VPN) Encryption .............................................................9
2.2.5 Local Enclave LAN IDS ........................................................................................10
2.2.6 Modem Pools (Dial-in Access) ..............................................................................10
2.2.7 Content Security Checking .....................................................................................10
2.2.8 Intrusion and Misuse Deterrence System (IMDS) .................................................11
2.3 Demilitarized Zone (DMZ) ...............................................................................................11
2.4 Computing Environment ...................................................................................................11
2.4.1 Operating System (OS) Security ............................................................................12
2.4.2 Host-based IDS .......................................................................................................12
2.4.3 Content Security Checking .....................................................................................13
2.5 Application Security .........................................................................................................13
2.5.1 World Wide Web (WWW) Applications ...............................................................13
2.5.2 E-mail Systems .......................................................................................................15
2.5.3 Mobile Code ...........................................................................................................15
2.5.4 Database Applications ............................................................................................17
2.5.5 Domain Name Service (DNS) ................................................................................17
2.6 Personal Digital Assistants (PDAs) ..................................................................................18
3. VULNERABILITY ASSESSMENTS......................................................................................21
4. INFORMATION ASSURANCE VULNERABILITY ALERT (IAVA) PROCESS ...............23
5. SOFTWARE DEVELOPMENT GUIDANCE.........................................................................25
5.1 Purpose..............................................................................................................................25
5.2 Recommendations .............................................................................................................25
5.3 Protocols ...........................................................................................................................25
5.4 Operating Systems (OSs) ..................................................................................................25
5.5 Encryption .........................................................................................................................26
5.6 General Considerations .....................................................................................................26
5.7 Software Development References ...................................................................................26
5.7.1 Microsoft Windows NT OS....................................................................................27
5.7.2 UNIX OS ................................................................................................................27
iii
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
6. DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION AND EXTENSION
REQUIREMENTS .........................................................................................................................29
6.1 Guidance ...........................................................................................................................29
6.2 Enclave Security Implementation Description Process ....................................................29
6.3 Enclave Security Extension Process .................................................................................30
SUPPLEMENT 1: ENCLAVE FIREWALL GUIDANCE ..........................................................31
S 1 Purpose .............................................................................................................................31
S 2 Firewall Implementation Guidance ..................................................................................31
S 2.1 Allowed Firewall Architectures .............................................................................31
S 2.1.1 Dual-homed ..............................................................................................31
S 2.1.2 Screened Host ...........................................................................................32
S 2.1.3 Dual-homed with Screened Subnet ..........................................................33
S 2.2 Firewall Placement .................................................................................................34
S 2.3 Employment Guidance ...........................................................................................34
S 2.4 Reporting ................................................................................................................35
S 2.5 Architecture ............................................................................................................35
S 2.6 Authentication ........................................................................................................36
S 2.7 Resistance to Attack ...............................................................................................36
S 2.8 Configuration .........................................................................................................37
S 2.9 Auditing and Administration..................................................................................38
S 2.10 Duties ...................................................................................................................39
S 2.10.1 Firewall Administrators (FAs) ................................................................39
S 2.10.2 Users .......................................................................................................39
S 2.10.3 DISA Contractors ...................................................................................40
S 3 COTS Firewall Functional Review ..................................................................................40
S 3.1 Firewall Functions ..................................................................................................40
S 3.1.1 Access Control and Filtering ....................................................................40
S 3.1.2 Mobile Code Blocking ..............................................................................41
S 3.1.3 Identification and Authentication (I&A) ..................................................41
S 3.1.4 Encryption.................................................................................................41
S 3.1.5 Auditing ....................................................................................................42
S 3.1.6 Virus Scanning..........................................................................................42
S 3.1.7 Network Address Translation (NAT) .......................................................42
S 3.1.8 Protection Against Attack .........................................................................43
S 3.1.9 Administration ..........................................................................................43
S 4 Required Filtering Rules ...................................................................................................43
S 4.1 Network Services ...................................................................................................43
S 4.2 Risk Plan ................................................................................................................43
S 4.3 Understanding Table S 4.1 .....................................................................................44
TABLE S 4.1: REQUIRED FILTERING RULES .........................................................47
EXAMPLE 1: DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION
REPORT ..................................................................................................................................55
EXAMPLE 2: DISA ENCLAVE SECURITY EXTENSION REQUEST ............................57
EXAMPLE 3: MOBILE CODE TECHNOLOGY RISK EXTENSION REQUEST ............59
APPENDIX A. GLOSSARY OF TERMS ...................................................................................61
iv
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
APPENDIX B: ACRONYMS ......................................................................................................71
APPENDIX C. DOCUMENT REVISION REQUEST ................................................................75
v
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
vi
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
1. INTRODUCTION
1.1 Background
This Security Technical Implementation Guide (STIG) provides the information protection
guidance necessary to implement secure Information Systems (ISs) while ensuring
interoperability.
DISA ISs must have adequate safeguards, both technical and procedural, to ensure the security of
data processed. In general, DISA ISs must provide maximum feasible safeguards to achieve the
highest level of security possible. The actual safeguards used will be commensurate with the
operational requirements, information sensitivity level, and consequences of exploitation of the
specific DISA IS.
The majority of DISA ISs is connected to Local Area Networks (LANs) and use Wide Area
Networks (WANs) (e.g., the Non-Classified Internet Protocol Router Network [NIPRNet] or
Secret Internet Protocol Router Network [SIPRNet]) as the primary data transport mechanism.
Unfortunately an adversary attempting to compromise DISA information and ISs can exploit
these LAN/WAN connections. Providing an adequate level of information protection at an
acceptable cost is difficult in this type of environment.
This document is also aimed at achieving the objectives as identified in the Information
Technology Management (ITM) Strategic Plan, specifically Major Focus Area 3, Information
Assurance (IA). This document can be found at http://www.disa.mil/cio/itmsp97.html.
Backdoor service or access that avoids the use of DISA-approved security tools, products, and
security processes is prohibited.
1.2 Definitions
This STIG and the DISA Enclave Security Architecture define an integrated system supporting
Defense-in-Depth (DID). An enclave includes the “Enclave Perimeter” and “Computing
Environment” layers in the DID architecture. If the network goes across different security levels
(unclassified to classified), then Secret and Below Interoperability (SABI) documents and
appropriate Points of Contact (POCs) need to be reviewed/contacted to determine the proper
security requirements. Examples of enclaves within DISA are the Defense Enterprise
Computing Center-Detachments (DECC-Ds) and Regional Network Operations and Security
Centers (RNOSCs). The DISANET consists of multiple enclaves connected through the
NIPRNet.
An Enclave Perimeter includes those points where non-members of an enclave gain access to
resources and information within that enclave, or where members of the enclave, but not resident
within the enclave, gain access to resources or information within that enclave. This includes
those points at which the enclave connects to any WAN service, and those points where
members of that enclave obtain dial-up or remote access.
1
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Enclaves can be broken down into Security Domains or Communities of Interest (COIs).
This STIG will be based on the data, users, access requirements, and postulated threats. In
addition, all the security-related functions within a security domain should be essentially
identical. An example would be two sections of an organization that use the same security
policy, but have different sets of System Administrators (SAs) and separate authentication
databases. Even though the same security policy is in use in both sections, these two sections are
actually separate security domains. A security domain would require a firewall system at a LAN
to LAN interface, in addition to the firewall separating the LANs from the WAN at the enclave
perimeter.
Security
Domain
LAN
Security
Domain
LAN
Security
Domain
LAN
Router or
Switch
DMZ Server
Firewall
Perimeter
Router
Network IDS
DII
Wide Area
Network
Figure 1.1. High-level Schematic of the Enclave Security Architecture
2
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
1.3 Writing Conventions
Throughout this document, statements are written using the words “will” and “should.” The
following paragraphs are intended to clarify how these statements are to be interpreted.
A reference using “will” implies mandatory compliance. All requirements of this kind will also
be documented in the italicized policy statements in bullet format, which follow the topic
paragraph. This makes all “will” statements easier to locate and interpret from the context of the
topic. The site must adhere to the instruction as written. Only an extension issued by the CIO
will table this requirement. The extension will normally have an expiration date, and does not
relieve the site from continuing their efforts to meet the requirement.
A reference to “should” is considered a recommendation that further enhances the security
posture of the site. These recommended actions will be documented in the text paragraphs, but
not in the italicized policy bullets. All reasonable attempts to meet these recommendations will
be made. However, if certain factors limit the implementation of this instruction (such as
customer requirements), written documentation will be maintained explaining the reason why the
conditions cannot be met and what alternative implementation strategy is supplementing the
instruction.
1.4 STIG Distribution
Compliance with the applicable Security Technical Implementation Guide (STIG) is mandatory
for systems residing in a DISA facility and for any system directly administered by DISA. The
use of the principles and guidelines in this STIG will provide an environment that meets or
exceeds the security requirements of DOD systems operating at the C2 system high level,
containing Controlled Unclassified Information. In the interest of promoting enhanced security
for systems both inside DOD and within the Federal Government’s computing environments,
DISA encourages any interested DOD activity or party to obtain the applicable STIG from the
Information Assurance Support Environment (IASE) server. This server contains the latest
copies of any STIG, as well as checklists, scripts, and other related security information. The
server URL is https://IASE.disa.mil. The SIPRNet URL is http:/IASE.disa.smil.mil. The
IASE server may be accessed by all .mil and .gov addresses.
Personnel such as DOD contractors who legitimately need access to this information but do not
have a .mil or .gov address should contact the Field Security Operations Support Desk at DSN
570-9264, Commercial 717-267-9264, or e-mail to fso_spt@ritchie.disa.mil.
3
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
The only way to verify that you have the latest copy of a s is to check the IASE server. There
could be circumstances, however, such as distribution of a particular STIG to a group of people,
where it would not be practical for each intended recipient to individually access the IASE
server. In this case, distribution of this document in either soft copy or hard copy form to other
DOD or Government agencies is permitted as long as the following rules are observed:
-
Language, scripts, and other information can be copied into another agency’s internal
documents and modified if desired, but no changes will be made to a copy of any STIG
and/or distributed to anyone as a DISA document. All STIG changes will be made
through DISA Field Security Operations.
-
This document may be distributed to military personnel, civil service personnel, and
contractors working under contract to the Federal Government as long as the individuals
involved have a legitimate need to know and are involved in either software development
and testing, computer security, or systems administration for their organization.
-
Distribution can be made via diskette or other physical media or e-mail or hard copy.
-
Neither the STIG nor any substantial subset of the STIG will ever be posted to any web
page, ftp server, or other system open to the public.
If you have received this document through any means other than a direct download from the
IASE server, please note that there may be a more recent version available. You may obtain
access to the current copies of all the STIGs by following the instructions in the paragraphs
above.
1.5 Document Revisions
Change requests to this document may be submitted using the Document Revision Request form
in Appendix C. Forward the completed form to the following address:
DISA Field Security Operations
ATTN: STIG on Enclave Security Support
One Overcash Avenue, Building #1
Letterkenny Army Depot
Chambersburg, PA 17201-4122
The request may be mailed to this address, or it may be sent by e-mail to
stig_comments@ritchie.disa.mil. All change requests will be coordinated with the relevant
DISA organizations, as appropriate, before inclusion in this document.
4
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
1.6 INFOCON
The Information Operations Condition (INFOCON) recommends actions to uniformly heighten
or reduce defensive posture, to defend against computer network attacks, and to mitigate
sustained damage to DOD information infrastructure, including computer and
telecommunications networks and systems. It is the responsibility of the site to ensure
compliance with the CJCS INFOCON Memo, dated 10 March 1999. Additionally, the ISSM
(Information Systems Security Manager) will be responsible for developing any new
supplemental procedures that are required (or for modifying old procedures) in order to comply
with INFOCON guidance.

Sites will comply with INFOCON procedures in accordance with the CJCS INFOCON Memo
dated 10 March 1999.

ISSMs will develop supplemental procedures, as required, in consonance with INFOCON
guidance.
5
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
6
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2. ENCLAVE SECURITY GUIDANCE
2.1 Traditional Security
Traditional Security, as part of Enclave Security, requires the vetting of individuals who control,
operate, design, and/or manipulate networks/data to ensure their trustworthiness, loyalty, and
reliability. It also incorporates physical security protective measures using the DID philosophy.
These measures include a security program consisting of layered and complementary security
controls, approval and certification of controlled areas, perimeter barriers, random guard patrols,
and closed circuit video that are sufficient to deter, detect, respond, and neutralize any threat
and/or unauthorized entry and movement within a facility.
2.2 Enclave Perimeter Security
Enclave Perimeter Security mechanisms are employed at the boundary between a DISA private
LAN and a WAN (e.g., NIPRNet, SIPRNet). These connections are discussed in this document
as “LAN to WAN” connections.
Current technology limits the ability to implement Enclave Security on Asynchronous Transfer
Mode (ATM) networks; therefore, direct ATM connections between an enclave and WANs are
not authorized.
Enclave protection mechanisms are also used to provide security within specific security
domains. In general, enclave protection mechanisms are installed as part of an Intranet used to
connect networks that have similar security requirements and have a common security domain.
A large, complex site, such as a Defense Enterprise Computing Center (DECC) or DECC-D,
may have multiple security domains with protection mechanisms tailored to the security
requirements of specific customers. For example, Defense Finance and Accounting Service
(DFAS) and Defense Logistics Agency (DLA) may have functionally driven security domains.
There might also be technology-driven security domains for Multiple Virtual Storage (MVS),
Unisys, Tandem, etc. Smaller DISA locations may have a single enclave with a single security
domain supporting the entire organization. The enclave or system owner will identify security
domain requirements in the System Security Authorization Agreement (SSAA).
Procedures outlined in the DOD Information Technology Certification and Accreditation
(DITSCAP) lay out the process that provides discipline as the Enclave Security and Architecture
are applied to specific requirements. Each SSAA will include a description of the architectural
implementation of the security requirements identified in this STIG.
DISA Security Technical Implementation Guides (STIGs) and Security Readiness Reviews
(SRRs) provide the specifications, standards, and inspections for each of the key enclave
components.
Enclave Perimeter Security mechanisms are described in the following sections.
7
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.2.1 Enclave Perimeter Network Intrusion Detection System (IDS)
The Network IDS is the first layer of defense in the DID architecture. This network based IDS
capability will detect, analyze, and collect intrusive behavior occurring on networks using
Internet Protocol (IP). The Network IDS is passive, so intruders are not aware of its presence.
Data can be analyzed real-time or collected for retrospective analysis. Alarms are generated
based on event rules.

Each DISA location will install and maintain a Network IDS at their Enclave Perimeter.

The Enclave Perimeter Network IDS will be under the operational control and configuration
management of the appropriate Regional Computer Emergency Response Team (RCERT).
Whenever possible, the Enclave Perimeter IDS will be positioned outside of any local
firewalls so that the RCERTs have visibility of all attempted malicious activity.

The Enclave Management Control Board (EMCB) will approve any exception to this STIG.

The Global Network Operations and Security Center (GNOSC) will review and approve
requirements for Enclave Perimeter Network IDS to ensure integration with the Sensor Grid.
2.2.2 Router Access Controls
A Router Access Control List (ACL) provides a basic level of access control over network
connections based on the site’s local security guidance. These controls include restrictions on
incoming and outgoing connections, as well as on connections between LAN segments internal
to the site/enclave. These restrictions are based on the source and destination addresses of the IP
packet as well as the service type (e.g., Simple Mail Transfer Protocol [SMTP], e-mail, Telnet,
and HyperText Transfer Protocol [http]).

Each DISA location will implement router ACLs based on a policy of Deny by Default with
blocks on all services and protocols not required by the site.

Services and protocols with known vulnerabilities will be allowed only to required source
and destination IP addresses.

Egress filtering rules will be applied denying all outbound traffic with illegitimate (i.e., not
local network) IP addresses. This is to prevent DISA enclaves from being part of a
Distributed Denial of Service (DDoS) attack. (See http://www.sans.org/dosstep/index.htm
for more information.)

The EMCB will address any exceptions to this through the Enclave Security Extension
process.

DISA Field Security Operations (FSO) will develop and maintain sample router ACLs for
typical DISA environments.
8
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.2.3 Enclave Firewall
Enclave Firewalls will be configured with the most restrictive security rules possible (“that
which is not expressly allowed is denied”). Configuration guidance can be found in
Supplement 1. It includes firewall implementation requirements, modern Commercial-Off-The
Shelf (COTS) firewall functions, the firewall implementation reporting and extension process,
required filtering rules, and guidance for developing firewall compatible applications.

The required guidance will be implemented at each site perimeter using a combination of
router ACLs and firewall controls.
2.2.4 Virtual Private Network (VPN) Encryption
Commercial VPN mechanisms may be used for encryption of unclassified and classified data
that will be handled at its original level (e.g., for privacy of secret data across the SIPRNet). To
provide for interoperability, Internet Protocol Security (IPSEC) based mechanisms will be used
if available. IPSEC mechanisms will utilize 3DES with 168 bit encryption keys. FIPS 140-1
certification of cryptographic modules with FIPS 46-3 compliant 3DES implementations is
recommended. FIPS 46-3 (approved 18 November 1999) states that 3DES is the FIPS approved
symmetric algorithm of choice. FIPS 180-1 keyed SHA-1 implementations for data
authentication and integrity is preferred, but keyed MD5 is an acceptable substitute if SHA-1 is
not available.
VPN encryption may be employed within an enclave to provide security domain security across
a DISA or DISA/Customer Intranet shared with other security domains or across a public
network. Since VPN is not a DISA standard, applications using VPNs are not always compatible
with other implementations. However, for DOD internal traffic DISA will evolve to increased
use of VPNs on the NIPRNet. VPNs are an acceptable solution for networking applications
using ports or protocols that are no longer authorized based on requirements in this STIG.
DISA activities that communicate via VPNs are responsible for identifying and agreeing to all
external connections for each DISA-managed network, agreeing to the policies enforced by
firewalls on each DISA-managed network, and accepting the residual risks of each
DISA-managed network connected by the VPN.
A variety of VPN configurations may be used within DISA depending on the functional
requirements and throughput.

At a minimum, all VPN solutions will include a network IDS on the unencrypted portion of
the network.
9
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.2.5 Local Enclave LAN IDS
Each DISA location will install, maintain, and operate a Network IDS inside of their network
enclaves. The Enclave Network IDS will monitor internal network traffic and provide real-time
alarms for network-based attacks. Either the RCERT or the local staff may control the enclave
Network IDS rules and attack signatures; however, D33 will provide second-level technical
support and configuration management. The site may establish a support agreement with the
RCERT for monitoring. The local staff is responsible for initial response to real-time alarms.
Significant incidents are reported to the site’s RCERT. Extensions will be granted by the EMCB
on a case-by-case basis.

Each DISA enclave will include a network IDS configured for real-time alarms.
2.2.6 Modem Pools (Dial-in Access)
Modem Pools used within the Enclave Security Architecture must be located in controlled areas
for physical protection and connected to a Remote Access Server (RAS) to provide electronic
authentication of all in-coming calls. The RAS must be configured within the security
architecture to accept and authenticate calls from the modem pool prior to making connection to
the requested IS.

Physical protection will be provided to prevent unauthorized device changes

Telephone lines for Modem Pools will be restricted and configured to their mission required
purpose of inward dial only or outward dial only.

All modem lines will be restricted to single-line operation and be configured without any
special features such as call forwarding.

Automatic Number Identification (ANI) will be used, if available, to enable review of the
modem call logs on a periodic basis.
2.2.7 Content Security Checking
Many forms of computer information can contain harmful content including viruses, macro
viruses, Trojan Horse programs, etc. These malicious programs can be transmitted across a
network in a number of ways including SMTP e-mail attachments, ftp file downloads, and Java
applets. Incoming data can be checked for harmful content at the public network boundary.
Numerous COTS products exist that can perform this type of content security checking. Two
such products, Norton Anti-Virus and McAfee Anti-Virus, are available on the DOD-wide virus
detection tool site license. (See http://www.cert.mil/.)

All DISA networks will employ Content Security Checking mechanisms for e-mail with
attachments, ftp data, and http data. Products from the DOD standard anti-virus contract
will be used.

Updated virus detection signatures will be downloaded and installed, at least weekly, from
the http://www.cert.mil or http://www.cert.smil.mil web site.
10
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001

Field Security Operations
Defense Information Systems Agency
Content security checking will be in the enclave firewall or in a mail proxy server. Content
security checking on the e-mail server is an acceptable interim solution.
2.2.8 Intrusion and Misuse Deterrence System (IMDS)
IMDS is a security tool designed to deter actual network intrusions and misuse by creating a
virtual simulated view of a site’s network and services. This virtual network view will appear to
be a lucrative target to intruders. IMDS detects, documents, and tracks any attempted scans,
logons, and/or attacks against the simulated network. The information from the system will feed
the same alert and reporting mechanisms as the site’s real systems. IMDS is an optional enclave
detection tool used at the discretion of the enclave owner. When used, it will be configured to
report to both the local staff and the RCERT. The IMDS application is available from DISA
Field Security Operations.
2.3 Demilitarized Zone (DMZ)
A DMZ will be established within the Enclave Security Architecture to host any publicly
accessible systems (e.g., ECEDI, public web servers, mail servers, external Domain Name
Service [DNS], X.500 directories, etc.). The approved architecture is to build the DMZ on a
separate branch (network interface) of the Enclave Perimeter firewall. (This is the Dual-homed
with Screened Subnet Firewall Architecture (DMZ) discussed in Supplement 1.) All DMZ traffic
would be routed through the firewall for application-level processing and the DMZ would still be
kept separate from the rest of the protected network. This method could cause load problems on
the firewall if a critical amount of traffic is passing between the outside and the DMZ. If this is
the case, the load issue could affect non-DMZ traffic between the protected network and the
outside. Multiple firewalls or load balancing could mitigate this situation if it is predicted to be a
problem.

A DMZ will be established within the Enclave Security Architecture to host any publicly
accessible system.

The DMZ will be placed on a separate firewall interface from the protected network.
2.4 Computing Environment
Computing Environment security mechanisms provide the innermost layer of defense for DISA
ISs. The security mechanisms are implemented on the actual end systems including NT
workstations, NT servers, UNIX workstations, UNIX servers, and mainframes. Computing
Environment security mechanisms are described in the following sections.
11
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.4.1 Operating System (OS) Security
Security features of OSs will be configured in a standardized manner to provide maximum
feasible safeguards with the highest level of security possible. These configurations will be
periodically checked via an automated mechanism and reapplied, as required.

DISA Enclaves will only use OSs with an EAL4 or higher rating (Common criteria
replacement for C2).

OSs that do not contain EAL4 level security features (including Windows 3.1, DOS, Windows
95, Windows 98, Macintosh OS, and Linux) will not be used unless justified by a mission
requirement and approved by the EMCB. An example of such a mission requirement would
be organizations that develop applications that are used by non-DOD organizations and,
therefore, must be tested and supported using a variety of desktop OSs.

DISA host OSs will be configured according to the latest DISA STIGs. STIGs provide
configuration guidance to achieve an optimal level of security. Operational requirements
may prevent implementation of all STIG requirements. In these cases, exceptions will be
documented as part of the SSAA and approved by the Designated Approving Authority
(DAA). (For DISA systems it is the Chief Information Officer [CIO].)

Major new OS changes (e.g., Windows 2000) will not be installed until security guidance is
published unless approved by the EMCB. The EMCB will respond to a request for approval
within three months. While guidance is being developed, new OS versions can be loaded for
internal testing and evaluation in a limited access testing environment. STIGs can be
accessed at https://iase.disa.mil/ or http://IASE.disa.smil.mil/.

Following the procedures outlined in the DITSCAP, each SSAA will include the OS security
requirements in this section as part of the “System Architectural Description” and the
“Security Requirements and/or Requirements Traceability Matrix.”
2.4.2 Host-based IDS
Intrusion detection can also be provided at the system level. In many situations, full intrusion
detection at the enclave level may not be possible due to VPN or application layer encryption.

DISA servers will use host-based IDSs on all systems.

The local staff will be responsible for initial response to real-time server alarms.

The site will report significant incidents to the site’s RCERT.
12
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.4.3 Content Security Checking
Content Security Checking can also be provided at the system level. In many situations, full
content checking at the enclave level may not be possible due to VPN or application layer
encryption. In addition, only system-based Content Security Checking can be used to protect
workstations from malicious programs that are imported on floppy disks, CD ROMs, ZIP drives,
tapes, or other removable media.

All DISA workstations and servers will employ Content Security Checking mechanisms from
the DOD-wide anti-virus contract.

Content Security Checking mechanisms will be configured to run in a background mode and
scan files upon access.

Updated virus detection signatures will be downloaded and installed, at least weekly, from
the http://www.cert.mil or http://www.cert.smil.mil web sites.

DISA organizations will strongly encourage DOD employees to install the DOD-licensed
anti-virus software on the employees’ home computers. Organizations should publicize that
this software is available free for home use of DOD employees.

DISA organizations will implement procedures requiring files to be virus scanned before they
are attached to outgoing e-mail.
2.5 Application Security
Modern systems supporting DISA operations include a wide range of new technologies that
include both new capabilities and new vulnerabilities. The infrastructure services used by these
new applications must be secured just as the OSs and networks. Security configuration guidance
that is available for some of the infrastructure services supporting typical application
developments is described in the following sections.
2.5.1 World Wide Web (WWW) Applications
WWW is the primary means DISA uses to share information with the general public (see DISAI
630-225-7, Internet, Intranet, and World Wide Web, dated 6 September 1991.6). WWW servers
are highly visible targets for attackers. WWW servers support both publicly released
information, as well as DISA applications.

All web servers will be configured in compliance with the latest Web Application STIG
update. Operational requirements may prevent implementation of all STIG requirements. In
these cases, extensions will be requested from the EMCB. The STIGs can be accessed at
https://iase.disa.mil/ or IASE.disa.smil.mil.

Standard ports will be used.

Public servers, approved by the Public Affairs Office (PAO), will be isolated on a separate
LAN segment (DMZ) from all private DISA systems.
13
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency

Private web servers will be protected from unauthorized remote access at the enclave
perimeter and host levels.

All sensitive WWW applications will use 128-bit SSL encryption and migrate to Public Key
Infrastructure (PKI) as soon as possible.
Minimum web server authentication requirements are specified in the table below. Sensitive
WWW applications are defined as web sites that contain unclassified information that either has
not been approved for public release (i.e., For Official Use Only [FOUO]), or information that is
sensitive by aggregation.
TABLE 2.1. MINIMUM WEB SERVER AUTHENTICATION REQUIREMENTS
CONTROLS
Open
SECURITY
Unencrypted
Limited by Internet
Domain (e.g., .mil, .gov)
or IP address
Encrypted
Limited By User ID and
Password
Server Certificate Based
Encrypted
User Certificate Based
(Software) Requires PKI
User Certificate Based
(Hardware) Requires
PKI
Encrypted
SSL
Encrypted
SSL
Encrypted
DESCRIPTIONS
Non-sensitive, of general interest to the
public, cleared and authorized for public
release for which worldwide
dissemination poses limited risk for
DOD or DOD personnel, even if
aggregated with other information
reasonably expected to be in the public
domain.
Non-sensitive, not of general interest to
the public although approved and
authorized for public release (to include
foreign nationals), and intended for
DOD or other specifically targeted
audience.
Non-sensitive, but limited to a specific,
targeted audience.
FOR OFFICIAL USE ONLY (FOUO)
FOR OFFICIAL USE ONLY (FOUO)
and sensitive by aggregation.
FOR OFFICIAL USE ONLY (FOUO)
and sensitive by aggregation where extra
security is required due to compilation.
14
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.5.2 E-mail Systems
Government-owned, Defense Message System (DMS) approved e-mail systems will be used for
authorized, unclassified U.S. Government business. Unapproved accounts, such as HOTMAIL
or YAHOO, will not be used for official business unless specifically authorized to do so by the
CIO. Internet Service Provider (ISP) or web-based commercial e-mail systems will be approved
only when it is mission essential and government owned e-mail systems are not available. When
approved, users will take special precautions to ensure that any sensitive and/or classified
information is not released.

Classified information will not be transmitted over any communications system unless it is
transmitted using approved NSA security devices in addition to approved security procedures
and practices.

All mail connections to and from mail servers used for anonymous mail redirection are to be
blocked. Mail should be traceable to an individual and known servers. Any servers that
have the capability for anonymous mail redirection pose a threat to DOD systems and staff
without the possibility of attribution.
2.5.3 Mobile Code
Mobile Code is the term given to software modules obtained from remote systems, transferred
across a network, and then downloaded and executed on a local system. An example would be a
workstation or laptop, where the recipient executes the web browser without explicit installation
or initiation of execution.
-
Category 1 (Active X and Postscript). Technologies in Category 1 exhibit a broad
functionality allowing unmediated access to host and remote system services. Category 1
technologies have known security exploits with few or no countermeasures once access is
gained (e.g., all or nothing decision: run with full power or do not run at all). Category 1
mobile code technologies can pose a severe threat to DISA operations. However, the
implementations of some mobile code technologies differentiate between signed and
unsigned mobile code. These implementations can be configured to allow the execution
of signed mobile code while simultaneously blocking the execution of unsigned mobile
code. When Category 1 mobile code is signed and obtained from a trusted source, the
risk is reduced. Category 1 mobile code may be used in DISA information systems only
when the mobile code is signed with a DOD-approved PKI code-signing certificate and
the mobile code is obtained from a trusted source. Until a DOD-approved PKI
code-signing certificate is available, the DISA CIO will approve alternate commercially
available code-signing certificates. To the extent possible, all DISA computer systems
(e.g., hosts), workstations, and applications capable of executing mobile code will be
configured to disable the execution of unsigned Category 1 mobile code obtained from
outside the enclave boundary. In situations where the use of unsigned Category 1 mobile
code is critical to the performance of a mission, a written extension request for its use
may be approved by the DISA CIO (see Example 3 in Supplement 1). The extension
request will be attached to the accreditation package as part of the System Security
Authorization Agreement (SSAA) required by DODI 5200.40. All DISA activities are
strongly encouraged to configure all end systems to disallow the execution of
15
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
downloaded Category 1 mobile code. Category 1 mobile code should also be blocked at
the enclave boundary.

-
Category 2 (Java, MS Office VBA, Lotus, PerfectScript). Category 2 Mobile Code
technologies have partial functionality allowing mediated access and
environment-controlled access to host system services. Category 2 technologies may
have known security exploits, but also have known fine-grained, periodic, or continuous
countermeasures/safeguards. Category 2 technologies may be used if they are obtained
over a trusted channel (i.e., PKI server certificate, SSL, or SIPRNet) from sources
specifically known to be trustworthy. All trusted channels will use some form of
encryption. Where feasible, protections against malicious forms of Category 2 mobile
code will be employed at the end-user workstation and at the enclave boundary. In
addition, unsigned Category 2 mobile code, whether or not obtained from a trusted source
over an assured channel, may be used it if executes in a constrained environment without
access to local system and network resources (e.g., file system, Windows registry,
network connections other than to its originating host). Where possible, web browsers
and other mobile code enabled products will be configured to prompt the user prior to the
execution of Category 2 mobile code. Where feasible, protections against malicious
Category2 mobile code technologies will be employed at end user systems and at enclave
boundaries. The DISA CIO may grant an extension (see Example 3 in Supplement 1) for
the use of Category 2 mobile code not obtained from a trusted source over an assured
channel. If code-signing is used to meet the requirement for a trusted source over an
assured channel, a DOD-approved PKI code-signing certificate will be used, if available.
In the absence of a DOD-approved PKI code-signing certificate, the DISA CIO will
approve alternate commercially available code-signing certificates.
-
Category 3 (JavaScript and PDF). Technologies in Category 3 support limited
functionality, with no capability for direct access to host system services. Category 3
technologies may have a history of known exploits, but also support fine-grained,
periodic, or continuous security safeguards. Category 3 technologies may be used in
DISA ISs.
-
Non-Categorized Mobile Code Technologies. Owing to the uncertain risk,
Non-Categorized Mobile Code Technologies are prohibited unless explicitly authorized
by the DOD CIO Control Board. This technology category will be blocked by all means
available at the enclave boundary, workstation, and application layer.
Category 1 and non-categorized mobile code will be blocked at the enclave perimeter.
16
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
2.5.4 Database Applications
Modern Database Management Systems (DBMSs) support distributed applications with security
services integrated into the DBMS. This shifting of security functions out of the OS requires
implementation of a security policy within the database itself. Controls such as password policy,
auditing, and Discretionary Access Control (DAC) must be configured in the DBMS consistent
with the OS security policy.

All DISA DBMSs will be configured in compliance with the latest Database STIG.
2.5.5 Domain Name Service (DNS)
DNS is an essential capability within the DISA network infrastructure that provides the
translation capability between host names and IP addresses. Because DNS is such an essential
capability, it represents a significant potential target of opportunity for cyber-attacks.
The DNS architecture is essentially a distributed database. As hosts are added, dropped, or
modified, the controlling organizations for the respective domains, such as that for .com, provide
an update to the DNS database. The update is replicated throughout the DNS architecture until
every host has the update, or at a minimum, knows where to find it. Denial-of-Service (DoS)
attacks against a DNS server are accomplished through preventing host name resolution or
database updates. Corruptive attacks are achieved by accepting database updates from
unauthorized sources. The result of a corruptive attack is that host names are mapped to
incorrect IP addresses.

All DISA DNS servers will comply with the following guidelines:
-
A split DNS service is required of all DISA locations operating DNS servers. The
externally visible piece of the split DNS will reside on the bastion host or on another host
in the DMZ. The externally visible DNS server will not include information on systems
inside the protected enclave. It may show information about those machines in the DMZ
that must be accessed by people outside the enclave. The external server must deny
“recursive” queries.
-
The internal server(s) will serve DNS queries from inside the enclave. It may contain
complete information about machines and addresses inside the enclave. Preferably, the
internal functions of authoritative DNS server (for local zones) and caching recursive
server (for remote DNS zones) will be performed by separate systems. Any internal
server that accepts recursive queries will be configured to limit recursive access to
authorized network clients (“allow recursive” directive).
-
DNS services will be implemented using the latest BIND version of DNS. Contact DISA
Field Security Operations for additional implementation recommendation of DNS
services. A segmented version is available for Global Command and Control System
(GCCS) and Common Operating Environment (COE) systems.
17
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
-
Zone transfer will be allowed only between authorized master and slave DNS servers
(“allow-transfer” directive) and other requests will be denied. The DNS Security
Extensions (DNSSEC) are still in development and will provide a stronger means to
authenticate DNS data. As this capability becomes mature, DISA Field Security
Operations will provide technical guidance.
-
DNS administrators will implement the latest applicable DOD Computer Emergency
Response Team (CERT) bulletin recommendations. Contact DISA Field Security
Operations for advice on the appropriate patches.
-
Local DNS updates will be performed directly from the console of the computer hosting
the DNS service. In the event that remote update is implemented, this will be
accomplished using Secure Shell (SSH) or an equivalent encrypted connection.
2.6 Personal Digital Assistants (PDAs)
PDAs (e.g., Palm Pilots, Windows CE devices, cell phones, and pagers with Internet access) are
powerful devices that can be connected within the enclave, but with potential additional risk if
not properly managed. Three levels of connectivity are possible—serial connectivity to a user
workstation within an enclave, dial-up connectivity through a communications server, and direct
Ethernet-based network connectivity.
When connected to enclaves within DISA only as a peripheral to a secured user workstation, the
workstation security provides the primary protection with the PDA acting as a sophisticated data
entry and storage extension to the secured workstation.
Connection from a PDA to a DISA network is authorized through a secured dial-up RAS
communications server only. The PDA device establishes a Point-to-Point Protocol (PPP)
connection to a DISA enclave via a user account set up on the network or directly on the
communications server. Account information security must be provided by the use of a secure
authentication protocol such as CHAP, MSCHAP, or SPAP.
The 3COM Palm Pilot and Windows CE devices can establish a secure dial-in PPP connection to
a Windows NT network. Dependent upon the communications/RAS server installed, users will
either connect to their network account or to a separate account set up on the communications
server. Once this connection is established, these devices can be used to access network services
as follows.
An IMAP4 e-mail application available for the 3COM Palm Pilot can access Microsoft
Exchange or Lotus e-mail servers over this connection. Although the application only supports
clear-text authentication for logging on to the Windows NT e-mail server, the connection
between the remote device and server will be encrypted through SSL, which is supported by the
remote e-mail application and the e-mail servers. Encrypting the traffic between the remote
device e-mail applications and the e-mail server provides an adequate substitution for SPAP or
CHAP secure user authentication and is a viable solution, provided the trust relationship can be
established between the e-mail server and the client.
18
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Upon logging onto the network with a Windows CE device, users can access enclave Windows
NT servers and services via a remote-control connection to a Citrix Metaframe server (an
extension to Microsoft Terminal Server). This functionality maintains all standard Windows NT
security capabilities.
Based upon the existing capabilities of PDAs, the implementation of the DISA/DOD PKI and
Smart Card infrastructure within the next two years would place severe limitations on the use of
these devices within DISA enclaves.

A direct Ethernet connection by PDAs to a DISA network will not be allowed.

There will be restrictions on accessing data or services on DISA enclaves through a dial-up
connection from PDAs.

PDA users will secure the PDA device as they would a notebook computer or sensitive
organizational files.
19
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
20
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
3. VULNERABILITY ASSESSMENTS
An ongoing program for vulnerability assessments is a key aspect of Phase IV, Post
Accreditation Compliance Validation, specified in the DITSCAP.
A combination of independent vulnerability assessments and ongoing self-assessments will be
used to ensure the controls listed above are properly maintained. The assessments will include
both host-based SRRs and penetration tests.

Each site will operate and maintain online automated vulnerability assessment tools for each
server on their network to include systems managed remotely by another organization. The
server configurations will be reviewed at least monthly to ensure compliance with the
appropriate security configuration policy.

D3 will provide penetration tests and SRRs for all operational DISA locations. Penetration
tests will be run at least twice per year with results provided to the site Chief and
summarized for the CIO and D3. SRRs will be conducted on a sample of systems at each
location at least annually.

D3 will procure, deploy, install, and provide training for enclave security IA tools that
support the Enclave Security Architecture. D3 will identify to D6 any new operational issues
that will require changes to the Enclave Security Architecture.
21
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
22
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
4. INFORMATION ASSURANCE VULNERABILITY ALERT (IAVA) PROCESS
The Assistant Secretary of Defense (ASD) for Command, Control, Communications, and
Intelligence (C3I) has directed that all DOD Commanders-in-Chief (CINCs)/Services/Agencies
(C/S/A) develop and implement a methodology to ensure that the SAs receive, acknowledge, and
comply with the DISA IAVA program. This program provides timely indication and reporting
of validated security holes relative to DOD systems/networks.
Vulnerability Compliance and Tracking System (VCTS), a web-based application, was
developed to support IAVA. It was developed as a means to establish a notification compliance
process and vulnerability tracking database.

All DISA assets that support enclave protection will be registered and tracked for
compliance in VCTS.
23
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
24
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
5. SOFTWARE DEVELOPMENT GUIDANCE
5.1 Purpose
The following sections outline basic guidance for software developers who incorporate security
mechanisms into new applications that pass traffic between network boundaries. Applications
should be developed in a manner that supports the integrity of the internal and external
connectivity provided by firewalls. Additionally, applications should not require configurations
in the firewall that would negate the effectiveness of the firewall.
5.2 Recommendations
The recommendations in the following sections provide general guidance for integration of
security in applications that need access through a DISA firewall. This includes development
guidance for protocols, OSs, and encryption.
5.3 Protocols

If possible, developers should use the protocols defined in Paragraph S 2.5 in Supplement 1
as “Allow” or “Conditional.”

Applications that use new protocols will have the protocols approved and included in
Paragraph S 2.5 in Supplement 1.

Protocols will not use random ports or non-fixed port numbers. Instead, static port
allocation should be used to avoid proliferation of possible vulnerabilities.

The distinction between outgoing calls and responses to them should be visible to packet
filters as much as possible with TCP.

Protocols that require the server to call the client back are very hard to manage in a firewall
environment. To the extent possible, new protocols should involve only outbound calls from
the client.

IP Services should not be modified and should be compliant with an associated Request For
Comments (RFC) standard.

Under no circumstances will an application or database program require a workstation to
perform IP packet forwarding functions.
5.4 Operating Systems (OSs)
Configure the baseline OS, either UNIX or Windows NT, in a secure manner. Use the latest
patches and plug for all known vulnerabilities. Specific vulnerabilities of Windows NT and
UNIX are not listed in this document, but may be found in the DOD-CERT documentation and
in the other DISA STIGs.
25
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
5.5 Encryption
Secure protocols should be used when additional assurance is necessary by the nature of the
application.
If an application’s traffic needs to be passed through the firewall, the application should support
tunneling and encrypted tunneling.
If authentication through the firewall is necessary, it should at least use the 128 bit Data
Encryption Standard (DES) encryption.
5.6 General Considerations
Under no circumstances should an application or database program undermine or substitute the
purpose of or use the system and security-related files and programs.
When using sequence numbers, the numbers should be chosen via a cryptographic random
number generator and should be at least 32 bits.
Applications should make their outgoing requests and responses visible to packet filters.
System applications should not connect to the firewall management system in any way.
Applications should not create trusted relationships outside, or bypass the firewall.
Applications should not be created with a script or software segment with an unknown author
(e.g., including a script downloaded from the Internet).
Use only trusted compilers and delivered executable software scripts. Unknown compilers could
potentially add a backdoor or unknown function(s) to the developer’s code.
Ensure that instructions are clearly distinguished from data.
Avoid features that introduce unconstrained programmability into an application.
Use programming techniques and languages that encourage construction of robust programs.
This would reduce frequency and severity of vulnerabilities.
5.7 Software Development References
The documents referenced in the following sections provide detailed guidelines for integration of
security applications that need access through a DISA firewall:
26
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
5.7.1 Microsoft Windows NT OS
Detailed security guidance for developing software to operate with the Microsoft Windows NT
OS may be found in the Defense Information Infrastructure (DII) Common Operating
Environment (COE) Windows NT Application and Kernel Developer’s Security Guidance
document dated July 1999.
5.7.2 UNIX OS
Detailed security guidance for developing software to operate with the UNIX OS may be found
in the DII COE UNIX Kernel Developer’s Security Guidance document dated June 1999.
27
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
28
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
6. DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION AND
EXTENSION REQUIREMENTS
6.1 Guidance
The CIO is responsible for maintaining a repository for the reported configuration data of all
DISA enclave security implementations and approving all exceptions to this guidance.
Additionally, extensions submitted for a connection to bypass a DISA-managed firewall require
D3 review and approval. The following sections provide the means for carrying out this
responsibility. This chapter outlines the reporting procedures to be followed for installing new
DISA-managed enclaves, for modifying existing enclave security architectures, and for
requesting an extension of any of the requirements of this document.
6.2 Enclave Security Implementation Description Process
This section describes the reporting process for installing new DISA-managed enclave security
products and for modifying existing DISA-managed security products.
Any installed enclave that has not been reported will follow the reporting process for new
DISA-managed enclaves.
All implementations of new DISA-managed enclaves will be reported to the CIO. DISA
organizations must complete the DISA ENCLAVE SECURITY IMPLEMENTATION
DESCRIPTION REPORT (see Example 1 in Supplement 1) and submit it to the CIO.
DISA organizations making modifications to current DISA-managed enclaves will also complete
the DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION REPORT and submit
the completed results to the CIO. Examples of a reportable change or modification include the
following:
-
Implementation of additional devices or computer systems that provide supplemental
enclave security services
New releases of OS or firewall software
New firewall hardware
New protocols and services through the firewall
Support for additional security functionality on the firewall (e.g., use of hardware tokens,
VPNs, third-party products)
If there is a requirement to change the configuration of a firewall that differs from the authorized
filtering rules in Paragraph S 4 in Supplement 1, then an approved extension must be submitted
with the DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION REPORT (see
Example 1 in Supplement 1). Section 6.3, Enclave Security Extension Process, describes the
extension process.
29
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
The CIO will perform an initial review of the report for completeness. If the CIO determines
that the description is complete, the description will be maintained in the DISA Enclave Security
Configuration Reporting Repository. Otherwise, the CIO will return the request to the DISA
organization for clarification.
6.3 Enclave Security Extension Process
This section describes the extension process for requesting any exception to enclave security
implementation requirements.
If there is a reason that any DISA-managed enclave cannot satisfy the requirements of this STIG,
then an extension request must be submitted with the DISA ENCLAVE SECURITY
IMPLEMENTATION DESCRIPTION REPORT. This includes, but is not limited to, exceptions
to protocols and services listed in Paragraph S 2.5 in Supplement 1. See Example 2 in
Supplement 1 for the sample DISA ENCLAVE SECURITY EXTENSION REQUEST.
If the CIO determines that the request is complete and valid, the description and request will be
forwarded to D6/IAESO. Otherwise, the CIO will return the request to the originator with an
explanation.
D6/IAESO will perform a technical review of the requested extension, prepare a
recommendation, and upon completion of the review, forward a formal recommendation to the
CIO.
If the CIO concurs with the D6/IAESO recommendation, the CIO will formally notify the
appropriate DISA organization of the results (e.g., approval to operate, need for additional
security measures or configuration modifications). If the CIO does not concur with the
D6/IAESO recommendation, the CIO will coordinate with D6/IAESO, and, if necessary, with
D3 to resolve the issues in a timely manner.
However, if the request is for a connection to bypass a DISA-managed firewall, then D6/IAESO
will forward the recommendation to D3. D3 will review the request and submit the decision to
the CIO. The CIO will then note the decision for the purpose of maintenance of the Enclave
Security Configuration Reporting Repository and formally notify the appropriate DISA
organization of the results.
CIO will be the Point of Contact (POC) for the entire process, including tracking and archiving
the request.
30
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
SUPPLEMENT 1: ENCLAVE FIREWALL GUIDANCE
S 1 Purpose
Firewalls are one aspect of a Defense-In-Depth (DID) security strategy. A firewall is one or
more computer systems or devices that enforce an access control policy between two networks.
This Supplement prescribes the policy for current and planned DISA firewalls and is intended to
facilitate the effective and uniform implementation of firewalls across DISA organizations.
S 2 Firewall Implementation Guidance
S 2.1 Allowed Firewall Architectures
The following sections present three different firewall architecture scenarios that can be
implemented to protect enclaves within DISA (i.e., Dual-homed, Screened Host, and
Dual-homed with Screened Subnet). Although these configurations can be set up in a number of
combinations to create hybrid solutions, the focus here will be on these three most common
architectures.
S 2.1.1 Dual-homed
In the classic Dual-homed Firewall Architecture (Figure S1.1), a host is set up as a gateway with
two Network Interface Cards (NICs), one connected to the external network through a router and
one connected to the internal network. Packet forwarding is disabled on the gateway and
information is passed at the application level. The gateway can be reached from both sides, but
traffic cannot directly flow across it.
Internal
Network
NIC 2
NIC 1
ROUTER
External
Network
Figure S1.1: Dual-homed Firewall Architecture
31
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
The router should also be set up with Access Control Lists (ACLs) or Internet Protocol (IP)
filtering so connections are allowed between the router and the firewall only. Some of the
disadvantages of using a Dual-homed host for a firewall is that it cannot forward packets, thus
requiring proxy services that must be configured manually. Additionally, performance is limited
as all network traffic must pass through one machine. On the other hand, today’s Dual-homed
firewalls offer quite a bit more functionality than the basic filter such as thorough auditing, virus
scanning, and Virtual Private Networks (VPNs).
The Dual-homed Architecture is a common choice for enclaves that do not require a
Demilitarized Zone (DMZ) to host public services (such as http or ftp). When performance is an
issue, more than one firewall can be implemented in a parallel configuration between the internal
and external networks. For example, this design may be implemented between an organization’s
Secret enclave and the Secret Internet Protocol Router Network (SIPRNet) (Local Area Network
[LAN] to Wide Area Network [WAN] connection). The enclave will not provide any web
services to the SIPRNet with this architecture in place. Configurations for providing web
services are discussed in the section below.
S 2.1.2 Screened Host
The Screened Host Architecture shown in Figure S1.2 involves the use of two filters. The
additional filter being used is between the screened host and its clients. The protected host is
known as a “Bastion Host.” This provides additional protection in comparison to a basic filter
configuration, but still lacks the auditing and address translation functions provided by a fullblown firewall. This architecture could be used in a LAN to LAN connection to isolate a
sensitive subnet from the rest of the enclave (e.g., to protect a Community of Interest [COI] LAN
or security domain LAN). This architecture should not be used to protect the boundary from
external sources.
Bastion
Host
Internal
Network
ROUTER
ROUTER
External
Network
Figure S1.2: Screened Host Architecture
32
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.1.3 Dual-homed with Screened Subnet
In Figure S1.3, Dual-homed with Screened Subnet Firewall Architecture (DMZ), a host is set up
as a gateway with three NICs—one connected to the external network through a router; one to
the internal network; and one to the DMZ. Packet forwarding is disabled on the gateway and
information is passed at the application level or the network layer, depending on the type of
firewall used. The gateway can be reached from all sides, but traffic cannot directly flow across
it unless that particular traffic is allowed to pass to the requested destination.
DMZ
Internal
Network
NIC 3
ROUTER
NIC 1
External
Network
NIC 2
Figure S1.3: Dual-homed with Screened Subnet Firewall Architecture (DMZ)
The router should also be setup with ACLs or IP filtering so connections are allowed between the
router and the firewall only. This configuration has some of the same disadvantages of the
regular Dual Home Architecture. However, the screened subnet provides external, untrusted
networks restricted access to the DMZ for services such as http or ftp. It allows the enclave
(with a LAN to WAN connection) to place its public servers in a secure network that requires
external sources to traverse the firewall and its security guidance to access the public servers, but
will not compromise the operating environment of the internal networks if one of the networks is
attacked by hackers.
The Dual-homed with Screened Subnet Architecture Firewall Architecture (DMZ) is required for
organizations that require publicly accessible systems (e.g., ECEDI, public web server, mail
server, external DNS, X.500 directories, etc.). When performance is an issue, more than one
firewall can be implemented in a parallel configuration between the internal and external
networks.
33
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.2 Firewall Placement
A firewall can be placed at several locations to provide protection from attacks. Each
implementation will differ depending on several key factors, including the sensitivity of the
networks, the network infrastructure, and the type of network traffic. Usually firewalls are used
to protect the boundaries of a network, although, at times, they can be used to secure a sensitive
part of an enclave from the rest of the enclave. There are three main points at which a firewall
can be implemented within a network:
-
At LAN-to-WAN/WAN-to-LAN connections
At LAN-to-LAN connections
At WAN-to-WAN connections
This guidance does not pertain to WAN-to-WAN connections.
LANs and enclaves can be classified as Top Secret, Secret, Controlled Unclassified Information
(CUI), and Unclassified. WANs also have different classification levels such as Joint
Worldwide Intelligence Communications System (JWICS), SIPRNet, Non-Classified Internet
Protocol Router Network (NIPRNet), and public or Internet. An example of a LAN-to-WAN
connection could be an unclassified enclave with a connection to the Internet. A LAN-to-LAN
connection could consist of two COIs (a CUI LAN interconnecting to another CUI LAN) within
the same enclave to allow separation from other groups and information sharing between the two
COIs. For example, to protect the privacy of sensitive financial, contractual, or personnel-related
information from general access. All of these connections are boundaries where a firewall is
required to ensure the confidentiality, availability, and integrity of the resources within that
boundary.
S 2.3 Employment Guidance
The following section sets forth guidance for employment of DISA-managed firewalls. This
guidance includes functional and doctrinal requirements.

To satisfy the level of security for DISA enclaves, only Commercial-Off-The Shelf (COTS)
firewall products that meet the criteria set forth in this section will be employed.

The firewall functions detailed in Paragraph S 2.2 in Supplement 1 will be used for
commercial firewall procurements. The site will document exceptions.
34
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.4 Reporting
A firewall implementation description (see Section 6.2, Enclave Security Implementation
Description Process) will be developed and maintained for each DISA-managed firewall. The
DISA organization’s System Security Authorization Agreement (SSAA) will be updated to
reflect the firewall installation or modification for the system using the firewall. Appropriate
references between documents are encouraged to reduce redundancy.

Modifications to a firewall configuration will be reported in accordance with Section 6.3,
Enclave Security Extension Process.

If the configuration cannot be maintained in accordance with the filtering rules in
Table S 4.1, Required Filtering Rules, an extension request will be submitted in accordance
with Section 6.3, Enclave Security Extension Process.

Apparent attacks or attempts to subvert the firewall will be reported to the Regional
Computer Emergency Response Team (RCERT) or the DOD Computer Emergency Response
Team (CERT) as soon as the attack or attempt is discovered.

DISA-managed firewalls will be subjected to random review and testing to verify compliance
with this STIG.
S 2.5 Architecture
Direct network connections between DISA-managed networks and the Internet, NIPRNet,
SIPRNet, or other external networks are not permitted.

All DISA networks will use application-level firewalls (or application-level gateways) to
secure connections to WANs. Application-level firewalls procured for DISA Information
Systems (ISs) will, at a minimum, include proxies for the following network applications:
Simple Mail Transfer Protocol (SMTP), Hyper Text Transport Protocol (http), http - over
Secure Socket Layer ([SSL] HTTPS), Network News Transfer Protocol (NNTP), Telnet, File
Transfer Protocol (ftp), Secure Shell (SSH), and RealAudio.

Connections that bypass or circumvent a DISA-managed firewall will be prohibited, except
where reviewed and approved by D3 and the Chief Information Officer (CIO). Connections
over SSH and SSL enabled applications allow users to encrypt their sessions. Such
encrypted sessions will be proxied at the firewall and will not be used to bypass or
circumvent DISA-managed firewalls.

A Dual-homed with Screened Subnet Firewall Architecture (DMZ) will be established by
organizations to host their publicly accessible systems (e.g., ECEDI, public web servers, mail
servers, external Domain Name Service [DNS], X.500 directories, etc.) within the DMZ.

Firewalls will be physically protected against unauthorized access.
35
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.6 Authentication

The firewall will, at a minimum, support a secure, non-spoofable, strong user authentication
system (e.g., MD5 based Skey, SecureID, Radius, or TACASs+, etc.).

Administrators will successfully authenticate before any transaction on their behalf is
allowed.

The firewall will uniquely identify and authenticate the claimed identity of a user before
granting access to the firewall's administration interface.

Only authorized authorities will have permission to change security guidance on the firewall.

Users on the internal or external side of the firewall will authenticate before using such
services as Telnet and ftp.

Only an administrator will access the firewall administration interface remotely.

The firewall will prevent the reuse of authentication data for administrators attempting to
access the firewall.

Inbound dial-in connections to a DISA-managed network may be used in conjunction with a
firewall or may be handled via other DISA-approved security safeguards (e.g., terminal
server). The placement and operation of dial-in servers and modems will be considered in
conjunction with firewalls so that consistent security perimeter protection guidance is
enforced.

A strong authentication challenge/response will be enforced for all inbound dial-in
connections to a DISA-managed network. This also applies to Firewall Administrators (FAs)
that dial-in to DISA-managed firewalls.

Firewalls that require the use of public key certificates will be interoperable with DOD
Security Management Infrastructure (SMI) and Public Key Infrastructure (PKI).

Content Security Checking of inbound packets, mail messages, and attachments will be at the
enclave firewall or mail proxy server.
S 2.7 Resistance to Attack

The firewall will protect against denial of service attacks such as ping sweeps, TCP SYN
floods, etc.

The Operating System (OS) platform for the firewall will be a secured version.

No general purpose capabilities will be on the firewall.

The firewall will not host public data.
36
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency

Users and administrators will be given only the permissions on the firewall required to do
their job.

The firewall and OS will be kept up-to-date with patches and bug fixes.

Accounts lock after a certain number of unsuccessful logon attempts and another
administrator will be required to unlock the account.

The firewall will mediate the flow of all information between users on an internal network
connected to the firewall and users on an external network connected to the firewall, and will
ensure that residual information from a previous information flow is not transmitted in any
way.

Upon initial start-up of the firewall or recovery from an interruption in firewall service, the
firewall will not compromise its resources or those of any connected network.

The firewall will protect itself against attempts by unauthorized users to bypass, deactivate,
or tamper with firewall security functions.

The firewall will provide functionality that enables an authorized administrator to use the
firewall security functions, and will ensure that only authorized administrators are able to
access such functionality.

The firewall will provide the means for an authorized administrator to control and limit
access to firewall security functions by an authorized external Information Technology (IT)
entity.

The firewall will be tested and shown to be resistant to attackers possessing moderate attack
potential.
S 2.8 Configuration
Table S 4.1, Required Filtering Rules, provides the filtering rules required for DISA-managed
firewalls. Users will configure their firewalls in accordance with these rules.

Only approved network protocols and services essential to the mission of a DISA
organization will be permitted to pass DISA-managed firewalls.

Protocols and services that are not expressly permitted will be prohibited.

Network Address Translation (NAT) will be used whenever possible as a means of hiding the
IP address on the internal network from the external networks.
37
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency

The System Administrator (SA) will have to set up local procedures to account for existing
users from within the internal network having registered their specific IP address with other
networks for host based security (e.g., TCP_WRAPPERS and/or other host based security
and authentication methods).

Procedures will have to be developed for firewall compatibility with the Vulnerability
Compliance and Tracking System (VCTS), which uses specific IP addresses from users’
workstations for access control.

Where application-level firewalls are employed, the application proxies provided by the
manufacturer will be used. The SA should only develop “plug proxies” for applications not
provided by the manufacturer.
S 2.9 Auditing and Administration

Firewall administration will be performed by qualified personnel who are specifically
trained in the operation and administration of the firewall.

At least two FAs will be identified for each DISA-managed firewall. FAs may also be
responsible for administering other systems (e.g., SAs).

Firewall log (audit) data will be reviewed on a daily basis by the FA, or other qualified
personnel, to determine if attacks or inappropriate use of the firewall have occurred.
Firewall log data will be archived for a minimum of one year.

The firewall, including system software, configuration data, database files, and log data, will
be backed up weekly so that the entire firewall configuration can be recovered in the event of
system failures or natural disasters. Frequent changes to critical firewall configuration files
(e.g., authentication database) may require daily backups.

Local access (e.g., console access) to the firewall will be restricted to authorized individual
FAs.

Remote management of firewalls over a network (e.g., in-band) will be restricted to
authorized individual FAs.

The firewall will have the following capabilities:
-
Log unsuccessful authentication attempts
Stamp audit trail data with the date and time when recorded
Record the Source IP, Destination IP, protocol used, and the action recorded
Log administrator logons, changes to the administrator group, and account lockouts
Protect audit logs from deletion and modification
Provide a means to record a readable audit trail of security-related events, with accurate
dates and times, and a means to search and sort the audit trail based on relevant
attributes
38
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.10 Duties
S 2.10.1 Firewall Administrators (FAs)
FAs are responsible for the following:
-
Complying with applicable security policies and procedures
-
Maintaining one or more DISA-approved firewalls in accordance with this supplement
-
Ensuring that the firewall only permits the protocols and services as approved by the CIO
-
Ensuring that additional protocols and services are not permitted through the firewall
without review and approval from the CIO, except when required for temporary
operations (consistent with Interim Authority to Operate [IATO] policy) and approved by
appropriate management
-
Supporting reviews and testing to verify compliance with this supplement
-
Seeking training to improve their knowledge and skills in the areas of network
technologies, firewall configurations, and Information Assurance (IA)
-
Performing backups of the firewall on a daily basis
-
Assessing the security posture (configuration) of the firewall on a random basis using
DISA-recommended tools and manual procedures
-
Monitoring the firewall for penetration attempts or attempts to evade security
-
Reporting security-related incidents to a DISA RCERT and registering with the
Information Assurance Vulnerability Alert (IAVA) VCTS database to receive
firewall-related vulnerability information
-
Monitoring the vendor's firewall mailing list or maintaining some other form of
communication with the vendor to be aware of required upgrades and patches
-
Seeking review and approval for all significant modifications to the approved firewall
configuration
S 2.10.2 Users

Users will comply with applicable security policies and procedures, not bypassing or
circumventing the firewall (e.g., by using modems or network tunneling software to connect
to the Internet or NIPRNet) without proper authorization.

Users will report security incidents and problems to the FA or appropriate security officer.
39
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 2.10.3 DISA Contractors
DISA contractors using DISA-provided equipment are required to comply with all aspects of this
policy. If a contractor is using a company-provided computer to conduct DISA business, then
the contractor must comply with established DISA guidance and procedures to include ensuring
that the computer is in compliance with the appropriate STIG.

DISA contractors will utilize one of the DISA approved anti-virus software applications.

All DISA contractors will follow established procedures before loading software/files onto a
DISA network.

Extreme care should be used on any files from a contractor's home or office computers since
they are not included in the DOD anti-virus program.
S 3 COTS Firewall Functional Review
S 3.1 Firewall Functions
The firewalls on the market differ from each other in many ways, but they all have similar
specific functions they use to protect boundaries. Different boundary points require different
levels of protection. The following describes the various functions that firewalls can serve. It
should be pointed out that not every firewall has all the functions discussed below.
S 3.1.1 Access Control and Filtering
Access Control and Filtering is the main function of every firewall. This function can be
accomplished in several ways ranging from a proxy at the application layer of the Open System
Interconnection (OSI) model to stateful inspection at the IP layer. By its nature, the firewall
implements a specific network security policy that corresponds to the level of sensitivity of the
boundary it is protecting. The fundamental purpose of enclave security guidance is to limit
access to the internal network from external sources. Only necessary inbound connections and
services should be allowed. The firewall also restricts the connectivity of internal users to
external destinations. Although internal users are generally trusted, they should be limited in
what services they can use through the firewall, so that they cannot unintentionally open security
vulnerabilities. The different firewall technologies offer different granularities of access control.
Some firewalls are now capable of what were traditionally guard-like filtering functions. For
example, firewalls incorporate software that filters access to either specific Universal Resource
Locators (URL) or categories of URLs. Certain ftp commands can be filtered while other
commands are allowed through the firewall. Technology will continue to develop in this area,
and very sophisticated and highly refined access control capabilities are likely to become
standard firewall features.
40
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 3.1.2 Mobile Code Blocking
Many firewall vendors now claim to offer Mobile Code Blocking. They claim that their
firewalls can block mobile codes such as Java applets, JavaScript, and/or ActiveX. This
capability has not reached the sophistication necessary to ensure that the internal network is
protected from mobile codes, and, in fact, firewalls cannot block the flow of code that is
embedded within objects (e.g., e-mail messages, HTML documents). Recently, products have
appeared on the market that are designed to provide gateway mobile code content inspection. It
is likely that all firewall products will begin to offer these features as part of the firewall
package, but currently these are add-on modules that should be purchased if required for the
sensitivity level of the data being protected.
S 3.1.3 Identification and Authentication (I&A)
I&A is one of the major functions provided by the different firewall products. External users
who require access to the internal network must be authenticated. Most security experts agree
that passwords are not a strong method of authentication. In fact, cracking user passwords is one
of the most common system attacks. Other authentication methods for screening access through
a firewall include one-time passwords, time-based passwords, and challenge-response schemes.
The most common one-time password system in use is S\key, a software-based authentication
mechanism using Message Digest 4 (MD4) or Message Digest 5 (MD5). S\key works by
starting with a seed and applying MD4 or MD5 to generate a sequence of keys. S\key encodes
the keys into a series of short words and prompts the user for the previous key (n-1), applies the
MD4 or MD5 to the user’s answer, and checks to see if the result is the key n that it knows.
Time-based passwords are a special form of one-time password. In these systems, the password
varies at a specified time interval based on an internal algorithm, thus adding the additional
complication of maintaining clock synchronization. Challenge-response systems are more
complex and involve something the user has (a smart card or Personal Computer [PC] card) and
something the user knows (password). Although it is possible to implement these systems in
software, using hardware tokens has numerous advantages. Commercial firewall products
support a wide range of authentication mechanisms.
S 3.1.4 Encryption
Encryption in firewalls can be used to provide a private, secure management pathway so that
remote management of the firewall is possible. Remote management also requires strong
authentication to ensure that the connection comes from a trusted source and that the data
remains confidential. Most firewalls on the market support this capability using a number of
different proprietary and public algorithms. In addition, encryption capabilities in firewalls are
used to establish VPNs. A VPN essentially carves out a private passageway over the Internet.
Although the use of VPNs is growing, widespread use of VPNs has not taken hold, primarily
because of interoperability issues. Implementations of the Internet Protocol Security (IPSEC)
protocols (the protocols used to establish VPNs) have been quite complex. Numerous vendors
are involved in performing interoperability testing of IPSEC security specification
implementations over the Internet. Firewalls also widely offer support for SSL, a security
protocol that provides communications privacy over the Internet.
41
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 3.1.5 Auditing
Auditing is a critical component of firewalls. The firewall provides an ideal place to log all of
the activity going on between networks. Most firewalls log the time, type of service, and source
and destination ports of incoming packets. Some firewalls allow the selection of certain events
to be logged. Firewalls can provide for automatic notification of the administrator via pager or
e-mail, depending on the type of access attempts. In some cases, the firewall can then attempt to
trace future attempts at access to gain more information about the attacker. When subjected to
various Denial-of-Service (DoS) attacks, some firewalls can either deny packets to guard against
the attack or shut down entirely. Despite these advances, current firewall technology falls short
in the area of reporting and alerts associated with the log files. Some firewall vendors are
partnering with third-party vendors to include intrusion detection and audit trail analysis tools
with their firewall offerings. However, as firewalls continue to incorporate more capabilities, the
complexity of the product increases, thus increasing the number of avenues for attack.
S 3.1.6 Virus Scanning
A few firewalls offer virus scanning software on the firewall itself, mainly through vendor
partnerships. Scanning for viruses on the firewall is difficult, simply because of the large
number of viruses that have been identified. In addition, the number of file formats that carry
viruses is far too numerous to scan at the firewall. To be effective, the firewall anti-virus
capability must be updated regularly to reflect the additional viruses discovered. Probably the
major obstacle to performing virus scanning on the firewall is the resulting reduction in
performance. Some networks overcome this obstacle by scanning for viruses entering the
network using a separate machine dedicated strictly to virus scanning. Virus scanning at the
network boundary does provide a first line of defense and can be used in combination with an
organization wide program for virus scanning at the desktop.
S 3.1.7 Network Address Translation (NAT)
The majority of firewalls available on the market today provide for NAT. NAT is a means of
hiding the IP addresses on the internal network from external networks. The need for IP address
translation arises in two cases:
1. The network administrator wishes to conceal the network’s internal IP addresses from the
Internet
2. The internal network’s IP addresses are invalid Internet addresses.
This technology thus provides advantages in security by hiding the internal network, and in
operational capability by giving the administrator more options for using IP addresses.
42
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
S 3.1.8 Protection Against Attack
Another important aspect of a firewall is how well it protects itself against attack. The firewall
should resist penetration, as breaking into the firewall will give a hacker access to the entire
network. Most firewalls run on stripped down versions of the OS. (Unnecessary executables,
compilers, and other dangerous files are removed.) In addition, some firewalls employ
technology that makes it extremely difficult for a hacker to penetrate the firewall OS. These
firewalls are built on trusted OSs or use mechanisms such as type enforcement to provide this
extra protection against penetration. Although these types of additional safeguards are
traditionally found on guard devices, firewalls are also beginning to offer this type of extra
protection against penetration.
S 3.1.9 Administration
Properly configuring the firewall components is critical to the security of the network. Most
vulnerabilities in firewalls arise from improper configuration and maintenance of the firewall.
For this reason, examining the administrative interface provided by the firewall is important. A
user-friendly interface will not, in and of itself, make the firewall any more secure; however, a
well-designed interface can ease the administrative burden and show how well the firewall has
implemented the security policy. Firewalls also use various self-monitoring tools. These tools
can provide additional access controls, can increase the auditing capability of the firewall, and
can provide for an integrity check on the file system of the firewall. Some of these tools are
proprietary and are provided with the firewall; other tools are available from the open source
code and can be used to enhance the security of the firewall.
S 4 Required Filtering Rules
S 4.1 Network Services
There are numerous types of network services available. Most services used to communicate
over the Internet are based on the following two transport protocols—Transport Control Protocol
(TCP) and User Datagram Protocol (UDP). This guidance addresses services based on the TCP
and UDP protocols. Non-IP protocols such as DECNET, SNA, SPX/IPX, AppleTalk, and X.25
will not be addressed.
S 4.2 Risk Plan
The Risk Plan mandated for DISA sites is to forbid all network traffic that is not expressly
permitted by policy. This helps protect against the misuse of unknown or flawed network
services. Before a user, either internal or external, can use a network service through a firewall,
network administrators (in consultation with firewall experts) must approve the network service
and configure the firewall to support it. Therefore, even if a user is capable of installing a
network service, that network service cannot be used until the firewall is configured to allow it.
The derivation of the filtering rules in Table S 4.1, Required Filtering Rules, based the need to
balance functionality with the known or perceived risks in allowing Internet traffic through the
firewall. Although this plan indicates services that can be supported, a firewall will be
configured to support a particular service only if there is a valid need for it.
43
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
The vulnerabilities described in this STIG are protected against manipulation from external
sources by the presence of a properly configured firewall. However, the vulnerabilities
themselves may still remain and may be exploited from within a firewall-protected domain
unless countermeasures (such as replacing exploitable programs with newer and corrected
versions) are taken.
S 4.3 Understanding Table S 4.1
Table S 4.1, Required Filtering Rules, identifies the guidance for handling services approved for
use with the firewalls being deployed by DISA. It addresses the inbound use of a service
separately from the outbound use of a service. In other words, the method of handling a service
originated from the Internet to the Enterprise LAN may differ from the method of handling the
same service when originated from the Enterprise LAN to the Internet. For the sake of
simplicity, filtering rules to/from the DMZ and the internal network have not been addressed.
Table S 4.1 specifically addresses the control of services/ports in and out of the internal network.
If a network is set up with a DMZ or Extranet segment(s), the firewall configuration will address
access control from the internal, external, and each Extranet segment(s) to each other (inbound
and outbound).
Before indicating whether or not a TCP or UDP service can be approved through the firewall, the
primary known risks of the service must be understood. In general, these risks include, but are
not limited to:
-
Unwanted intrusion into the network through the exploitation of known software
vulnerabilities
-
Passive interception of network traffic (sniffing)
-
Deliberate injection or modification of network packets designed to fool access controls
(hijacking or spoofing)
-
Delivery of data to a host to such a degree that there is a DoS on the victim host
(flooding)
-
Inclusion of Trojan Horses, viruses, and logic bombs with the data being delivered (data
driven attacks)
44
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Based on these primary risks and the capability of today's firewall technology, this guidance
recommends whether or not the firewall should be configured to support a required service.
However, even with a firewall in place, there will be some residual risk. For instance, data
driven attacks, such as viruses and Trojan Horses, may be introduced into a firewall-protected
network through the use of legitimate access protocols. Also, unencrypted traffic between
networks may still be susceptible to sniffing or spoofing attacks. Due to this residual risk, it is
best to prohibit a service unless there is a strong requirement for it.
Advances in firewall technology, which are taking place rapidly, are continuing to address the
risks associated with many network services. Because of this rapidly changing technology, this
guidance can only be considered a snapshot that represents how today's firewall technology can
support current networking services. Improvements in firewall technology may soon allow for
the passing of protocols that are not normally allowed to pass through.
45
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
46
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TABLE S 4.1: REQUIRED FILTERING RULES
KEY TO TABLE ENTRIES
Allow
Deny
Cond
Without this service the system may not be fully functional. Allow, if required. No
additional security controls necessary.
Possible source of entry for exploitation. If absolutely necessary, submit an
extension request documenting rationale and alternate protection used.
Conditional. Allow only where service is needed with controls such as source and
destination IP addresses, filtering, and strong authentication. Deny if not needed.
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
TCP
Mux
Echo
1
TCP
INOUTBOUND BOUND
Deny
7
TCP;UDP
Deny
Discard
9
TCP;UDP
Deny
Systat
11
TCP
Deny
Daytime
13
TCP
Deny
Daytime
13
UDP
Deny
Netstat
15
TCP
Deny
MSP, v2
18
TCP
Deny
Chargen
19
TCP;UDP
Deny
DESCRIPTION/NOTES
TCP Port Multiplexer. Rarely
used.
An echo server that can be
useful for seeing if a machine
is alive. A higher level
equivalent of ICMP echo
(ping). Can be used to probe
network configuration and
used for DoS attack.
CERT/CC 96-01 Denial of
Service
The dev/null of the Internet.
Harmless.
Occasionally connected to
netstat, w, or ps; a.k.a., user’s
protocol. Returns active users.
Time of day. Time has been
used in generation of
cryptographic keys.
Time of day. See above.
CERT/CC 96-01 Denial of
Service.
Network status. Obsolete
since 1994.
Message Send Protocol. See
RFC 1312 for security
considerations.
Character Generator.
CERT/CC 96-01 Denial of
Service (UDP).
47
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
FTP-data
20
FTP
TCP
INBOUND
Cond
OUTBOUND
Allow
21
TCP
Cond
Allow
SSH
22
TCP
Cond
Allow
Telnet
23
TCP
Deny
Cond
SMTP
25
TCP
Cond
Time
37
TCP;UDP
Deny
Whois
43
TCP
Login
49
TCP
Domain
53
TCP/UDP
TACACS-DS
65
TCP
Cond
Bootp
67
UDP
Deny
Bootpc
68
UDP
Deny
Deny
Allow
Deny
Cond
Allow
48
FOR OFFICIAL USE ONLY
DESCRIPTION/NOTES
Data channel for ftp. Hard to
filter. Relevant CERT/CC
Advisories: 97-27, 97-16, 9408, 94-07, 93-10, 93-06, 99-13,
DOD-CERT 1999-B-0003.
ftp control channel. Allow
only to your ftp server. See the
CERT Advisories listed under
ftp-data.
Secure shell remote login
protocol.
Telnet. Relevant CERT/CC
Advisories: 95-14, 95-03. Use
destination IP filtering and
strong authentication.
NOTE: Telnet sends
passwords in the clear.
Simple Mail Transfer Protocol.
See CERT/CC Advisory 95-05
for sendmail vulnerabilities.
Deny except for traffic to or
from known mail servers.
Time of day in machinereadable format. CERT/CC 9601 Denial of Service (UDP).
Internet user name directory
service.
Login Host Protocol. See
CERT/CC Advisories 97-21,
97-15, 97-06, 94-09, 93-12,
91-08 and DOD-CERT
Bulletins 94-19, 93-24.
Domain Name Service.
CERT/CC 99-14, DOD-CERT
2000-A-01.
TACACS-Database Service.
Control access to authenticate
clients.
Bootstrap protocol server. Not
required and exploitable.
Bootstrap protocol client. Not
required and exploitable.
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
TFTP
69
UDP
INOUTBOUND BOUND
Deny
Gopher
70
TCP
Deny
Finger
79
TCP
Deny
HTTP
80
TCP;UDP
Kerberos
88
UDP
Cond
X.500
102
TCP
Cond
ISO-Directory.
X.400
103
TCP
Cond
X.400 Electronic Mail.
X.400-SND
POP-2
104
109
TCP
TCP
Cond
Deny
POP-3
110
TCP
Deny
SunRPC
111
TCP;UDP
Deny
X.400 Electronic Mail.
Post Office Protocol - Version
2. See CERT/CC Advisory 9811, 98-07, 97-09.
Post Office Protocol - Version
3. See CERT/CC Advisory
98-11, 98-07, 97-09.
SUN Remote Procedure Call.
See CERT/CC Advisories 9811, 95-17, 94-02, and DODCERT Bulletins 98-08a, 95-49,
95-50.
Cond
Allow
DESCRIPTION/NOTES
Trivial File Transfer Protocol.
See CERT/CC Advisories 9118, 91-19.
Gopher server. Not required
and exploitable. See
CERT/CC Advisory 93-11 and
DOD-CERT Bulletin 93-21.
Finger. See CERT/CC
Advisory 93-04 and DODCERT Bulletin 93-06.
Hyper Text Transfer Protocol.
Deny incoming except to
DMZ, proxy outgoing. DODCERT 1999-A-10, 1999-A-9,
1999-A-7,1999-B-1,1999-T6,1999-T-3,CERT/CC 200002.
If Kerberos authenticated
logons are allowed, whether
directly or via inter-realm
authentication, this port must
be open. Otherwise, it should
be blocked. CERT/CC 96-03.
49
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
Auth
113
TCP
INOUTBOUND BOUND
Cond
SFTP
UUCP-path
115
117
TCP
TCP
Deny
Deny
NNTP
119
TCP
Cond
NTP
123
TCP;UDP
Statsrv
133
TCP
MS-RPC
135
TCP;UDP
Deny
Cond
NetBIOS-NS
137
TCP;UDP
Deny
Cond
NetBIOSDGM
138
TCP;UDP
Deny
Cond
NetBIOSSSN
139
TCP;UDP
Deny
Cond
Cond
Allow
Deny
50
FOR OFFICIAL USE ONLY
DESCRIPTION/NOTES
IP authentication service.
Identifies the username
associated with a TCP
connection. Can be spoofed.
Sends full name from
/etc/passwd if remote listening
to IDENTD. DOD-CERT
Bulletin 95-43. Incoming
Ident connections to Ident
daemon running on firewall
can normally be permitted.
Simple ftp.
UUCP Path Service. See
CERT/CC Advisory 92-06.
Network News Transfer
Protocol (nntp). Access should
only be given through local
nntp server and proxied.
CERT/CC 97-08, DOD-CERT
97-02.
Network Time Protocol.
Required by DMS and other
systems. CERT/CC 96-01
Denial of Service (UDP).
Statistics Service. See
CERT/CC Advisory 97-26 and
DOD-CERT Bulletin 96-12.
MS Remote Procedure Call.
Required for MS Outlook, etc.
Exploitable.
NETBIOS Name Service.
Exploitable. Brute forcible if
improperly configured.
Susceptible to denial of
service.
NETBIOS Datagram Service.
Exploitable. See NetBIOS-NS
service comments.
NETBIOS Session Service.
Exploitable. See NetBIOS-NS
service comments.
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
IMAP2, 4
143
TCP
SQL-Net
SNMP
150
161
TCP
TCP;UDP
SNMP-trap
BGP
162
179
TCP;UDP
TCP
IRC
194
TCP
Deny
IMAP3
220
TCP
Deny
SET
257
TCP;UDP
Cond
LDAP
389
TCP
Cond
Allow
HTTPS
443
TCP;UDP
Cond
Allow
IsaKMP
500
UDP
Cond
Key management protocol.
Rexec
Rlogin
512
13
TCP
TCP
Deny
Deny
Rwho
513
UDP
Deny
Rsh
514
TCP
Deny
Syslog
514
UDP
Deny
Remote process execution.
Remote login. See CERT/CC
Advisories 97-06, 95-15, and
94-09.
Remote who command.
Maintains database of who is
logged in to machines on a
local network.
Similar to exec, but automatic
authentication is performed for
login server.
Can gain access to audit logs.
Exploitable. See CERT/CC
Advisory 95-13.
INOUTBOUND BOUND
Deny
Cond
Deny
Cond
Cond
Deny
Deny
DESCRIPTION/NOTES
Internet Mail Access Protocol
v2. CERT/CC 98-11, 98-07.
SQL-NET. IP filter.
Simple Network Management
Protocol. Exploitable.
SNMPTRAP. Exploitable.
Border Gateway Protocol. Not
required for enclave.
Internet Relay Chat Protocol.
See CERT/CC Advisory 94-14
and DOD-CERT Bulletin 9333.
Interactive Mail Access
Protocol v3. See CERT/CC
Advisory 98-11, 98-07, 97-09.
Secure Electronic Transaction.
Use IP filtering.
Lightweight Directory Access
Protocol. Use IP filtering and
authentication.
http protocol over TLS/SSL.
DOD-CERT 1999-A-9.
51
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
Printer
515
TCP
INOUTBOUND BOUND
Deny
Talk
517
UDP
Deny
Ntalk
RIP
518
520
UDP
UDP
Deny
Deny
UUCP
540
TCP
Deny
Klogin
543
TCP;UDP
Deny
LDAPS
636
TCP;UDP
Flexlm
744
TCP;UDP
Kerberosadmin
SecureID
749
TCP;UDP
1024
TCP;UDP
PDA
1333
TCP
Lotus
Notes
ICA
1352
TCP;UDP
Cond
1494
TCP
Cond
SQL-Net
NFS
1521
2049
TCP
TCP;UDP
Cond
Deny
Cond
Allow
Deny
Deny
Cond
Cond
Deny
Cond
52
FOR OFFICIAL USE ONLY
DESCRIPTION/NOTES
Line printer spooler. See
CERT/CC Advisories 97-19,
95-15.
Actual talk protocol uses
random TCP ports. See
CERT/CC Advisory 97-04 and
DOD-CERT Bulletin 97-07.
Same as talk.
Outsiders can gain access to
routing tables. Exploitable.
Historically a dangerous
service, and mostly obsolete on
the Internet. See CERT/CC
Advisory 92-06.
See CERT/CC Advisory 9706.
LDAP protocol over TLS/SSL
(was sldap).
Flexible License Manager.
See CERT/CC Advisory 9701.
Kerberos administration.
Secure Identification for
remote access authentication.
PerDiemAmazing. Travel
orders and vouchers.
Lotus Notes. IP filtering based
on client and server location.
Citrix Independent Computing
Architecture.
Oracle SQL-Net.
NFS server daemon. See
CERT/CC Advisories 98-12,
96-09, 94-15, 94-02, 93-15,
92-15, 91-21, and DOD-CERT
Bulletin 1999-A-6, 1999-01,
94-41.
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
TCP/UDP PORT AND SERVICE FILTERING GUIDE
SECURITY
SERVICE
PORT
PROTOCOL
INBOUND
OUTBOUND
DESCRIPTION/NOTES
Calendar
X11
TCP
TCP
Cond
Deny
IRC
5730
60006020
6667
PNM
7070
TCP
Netscape calendar.
Block the entire range of X11
ports, if possible.
Internet Relay Chat. May or
may not be a security risk per
se, but some channels attract
the sort of network people who
send out ICMP Destination
Unreachable messages. See
CERT/CC Advisory 94-14 and
DOD-CERT Bulletin 94-33.
Streaming audio. Also
referred to as Real Audio.
DMS X.500
17003
TCP
Deny
TCP
Deny
Cond
Deny
Cond
X.500 for DMS.
NOTE: All ICMP traffic should be denied.
53
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
54
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
EXAMPLE 1: DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION
REPORT
INTEROFFICE MEMORANDUM
TO:
DISA Chief Information Officer (CIO)
FROM:
Site Name/Site Code
DATE:
dd mmm yyyy
SUBJECT:
DISA Enclave Security Implementation Description Report
PREPARER: Name/Site Code/DSN
1. DISA Organization reporting the firewall:
2. Brief description of the new firewall requirement (e.g., new subnet added, new lab installed,
or changing vendor product):
3. Technical POC for this Request (ISSO, ISSM, or Firewall Administrator [FA]) who will be
responsible for submitting this template to the CIO for follow-up questions):
Name:
Office:
Phone:
Title:
E-mail address:
4. Firewall Administrator (FA) for this request (include the qualifications and skills of the FA):
Name:
Office:
Phone:
Title:
E-mail address:
5. Location where firewall will be installed (i.e., building, room number, street address, city,
state). State the physical protection conditions (i.e., Sensitive Compartmented Information
Facility [SCIF], Network Operations Center).
6. Vendor of firewall product, model number, version number, and release of underlying OS or
system software (e.g., Solaris 2.5.1, Windows NT 4.0). Include the use of third-party
products used on or with the firewall (e.g., intrusion detection software, virus scanning, etc.).
55
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
7. Attach a copy of the firewall architecture diagram. The diagram will identify the networks
connected to the firewall and the assigned IP addresses and domain names of the firewall
machine(s). A system-wide diagram showing other firewalls in the environment or other
connections to external networks will be included.
8. Identify (a) protocols and services that are permitted to flow across the firewall, (b) how the
firewall is protected against unauthorized access (e.g., physical security, administrative
access to the firewall), (c) how the firewall configuration will be periodically examined or
tested to ensure the firewall continues to operate in the approved configuration, (d) required
and expected throughput, and (e) the roles and responsibilities associated with the firewall
(e.g., DISA organization management, designated FA, users).
9. Attach updated SSAAs to reflect the new firewall(s).
56
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
EXAMPLE 2: DISA ENCLAVE SECURITY EXTENSION REQUEST
INTEROFFICE MEMORANDUM
TO:
EMCB (Office of the Chief Information Officer [CIO])
FROM:
Site Name / Site Code
DATE:
dd mmm yyyy
SUBJECT:
DISA Enclave Security Extension Request
PREPARER: Name / Site Code / DSN
1. Site Name:
2. Enclave(s) Affected:
3. Domain ID (if pertinent):
4. Application(s) Affected:
5. Site POC (ISSO/TASO/ISSM/SM):
6. What is required for the exception:
7. Impact to the mission if the exception is not implemented:
8. How any security risk associated with the exception is to be mitigated:
9. Requested duration of the extension:
10. POC for this Request:
Name:
Office:
Phone:
Title:
Name:
Title:
57
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
58
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
EXAMPLE 3: MOBILE CODE TECHNOLOGY RISK EXTENSION REQUEST
INTEROFFICE MEMORANDUM
TO:
EMCB (Office of the Chief Information Officer [CIO])
FROM:
Site Name / Site Code
DATE:
dd mmm yyyy
SUBJECT:
Mobile Code Technology Risk Extension Request
PREPARER: Name / Site Code / DSN
1. Site Name:
2. Enclave(s) Affected:
3. Domain ID (if pertinent):
4. Application(s) Affected:
5. Site POC (ISSO/TASO/ISSM/SM):
6. Mobile code security product in use:
7. Security configuration of the mobile code security product:
8. Impact to the mission if the exception is not implemented:
9. How any security risk associated with the exception is to be mitigated:
10. Requested duration of the extension:
11. POC for this Request:
Name:
Office:
Phone:
Title:
Name:
Title:
59
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
60
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
APPENDIX A. GLOSSARY OF TERMS
Access – Establish logical or physical communication or contact. (JTF CND Taxonomy)
Access Control – The process of limiting access to the resources of a system only to authorized
programs, processes, or other systems (in a network). Synonymous with controlled access and
limited access. (Glossary of Computer Terms, GCSS Security Requirements)
-
Isolation of assets and information from unauthorized people and permission to access to
authorized personnel. (TAFIM Vol. 6 DGSA)
-
A means of preventing the unauthorized use of a resource or the use of a resource in an
unauthorized manner. (IW Legal, Regulatory, Policy and Organizational Considerations
for IA)
-
Provides a technical means of controlling what information can be used, what programs
can be run, and what modifications can be made by individual users.
Accreditation – A formal declaration by the Designated Approving Authority (DAA) that the
Automated Information System (AIS) is approved to operate in a particular security mode using
a prescribed set of safeguards.
-
The official management authorization for operation of an Automated Information
System (AIS) which is based on the certification process, as well as other management
considerations.
-
The accreditation statement affixes security responsibility with the Designated Approving
Authority (DAA) and shows that due care has been taken for security. (DODD 5200.28)
-
A process by which an organization accepts or rejects operational responsibility for
Information Systems (ISs) performance, including security. (TAFIM Vol. 6 DGSA)
Application-Level Firewall – A firewall that runs proxy services for common applications or
upper layer protocols, such as Telnet, File Transfer Protocol (FTP), and HyperText Transfer
Protocol (HTTP). Proxy services are specialized application or server programs that run on the
firewall. These programs accept requests and forward them, according to firewall policy, to the
actual services. Application-level firewalls often re-address traffic so that outgoing traffic
appears to have originated from the firewall, rather than the internal host. Also referred to as
application-level gateway, forwarder, proxy server firewall, or proxy-based firewall.
Assessment – An appraisal, by a trained team of professionals, to determine the state of an
organization’s current process, to determine the high-priority process-related issues facing an
organization, and to obtain the organizational support for process improvement. (SSE-CMM
v1.0)
61
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Assurance – A measure of confidence that the security features and architecture of an
Automated Information System (AIS) accurately mediates and enforces the security policy.
Requires testing. (DODD 5200.28)
Attack – The act of trying to bypass security controls on a system. An attack may be active,
resulting in the alteration of data; or passive, resulting in the release of data. (NOTE: The fact
that an attack is made does not necessarily mean that it will succeed.) The degree of success
depends on the vulnerability of the system or activity and the effectiveness of existing
countermeasures. The intentional act of attempting to bypass security controls on an Automated
Information System (AIS). (NCSC-WA-001-85)
-
A set of actions designed to compromise confidentiality, integrity, availability, or any
other desired feature of an Information System (IS).
Audit – The independent review and examination of records and activities to assess the
adequacy of system controls, to ensure compliance with established policies and operational
procedures, and to recommend necessary changes in controls, policies, or procedures.
Automated Information System (AIS) – An assembly of computer hardware, software, and/or
firmware configured to collect, create, communicate, compute, disseminate, process, store,
and/or control data or information. (IMDS SFUG)
Bastion Host – A system that has been properly hardened or fortified to resist attacks. Firewalls
are commonly hosted on bastion hosts. Bastion hosts are also employed for servers placed
outside of firewalls (e.g., external World Wide Web server, Anonymous FTP server).
Certification – The process of determining the effectiveness of all security mechanisms.
(TAFIM Vol. 6 DGSA)
-
The comprehensive evaluation of the technical and non-technical security features of an
Automated Information System (AIS) and other safeguards, made in support of the
accreditation process, that establishes the extent to which a particular design and
implementation meet a specified set of security requirements.
Circuit-level Gateway – A protocol gateway for a specific service type. Circuit-level gateways
relay TCP connections.
Class C Controlled Area – The area will have true floor to ceiling walls. There will be no
windows or the windows will be covered so that the inside area cannot be viewed. The area
must also be monitored by an intrusion detection system and have doors with access control
devices with alarms.
CND Sensor Grid – A coordinated constellation of decentrally-owned and implemented
intrusion and anomaly detection systems deployed throughout DOD information systems and
computer networks.
-
A subset of the NETOPS sensor grid.
62
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Communications Security (COMSEC) – Measures taken to deny unauthorized persons
information derived from telecommunications and to ensure the authenticity of such
telecommunications. Includes crypto-security, transmission security, emission security, and
physical security of COMSEC material. (CJCSI 6510.01B)
-
Encrypting communications by using an approved encryption algorithm.
Computer Emergency Response Team (CERT) – Formed by DARPA in November 1988 in
response to the needs exhibited during the Internet worm incident.
-
Works with the Internet community to facilitate its response to computer security events
involving Internet hosts; to take proactive steps to raise the community’s awareness of
computer security issues; and to conduct research toward improving the security of
existing systems.
Controlled Area – An area within which uncontrolled movement does not permit access to
classified information and which is designated for the principal purpose of providing
administrative control, safety, or a buffer area of security restrictions for Limited Exclusion
Areas. This area may be protected by physical security measures such as sentries and fences.
(OPNAVINST 5239.1A) (Source NISTIR: 4659)
-
An area or space to which access is physically controlled. (NCSC-9) (Source: NISTIR4659)
Defense-in-Depth (DID) – The security approach whereby each system on the network is
secured to the greatest degree. (NCSA)
-
Manages risk by balancing threat against system/data criticality to identify and
implement practical solutions.
-
The sitting of mutually supporting defense positions designed to absorb and progressively
weaken attack, to prevent initial observations of the whole position by the enemy, and to
allow the commander to maneuver his reserve (Joint Pub 1-02, 1994).
63
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Defense Information Infrastructure (DII) – Encompasses information transfer and processing
resources, including information and data storage, manipulation, retrieval, and display. The
shared or interconnected system of computers, communications, data, applications, security,
people, training, and other support structure serving the DOD’s local and worldwide information
needs.
-
Connects DOD mission support, Command and Control (C2), and intelligence computers
and users through voice, data, imagery, video, and multimedia services.
-
Provides information processing and value-added services to subscribers over the
Defense Information Systems Network (DISN). Unique user data, information, and user
applications are not considered part of the DII. (ASD [C3I] Memo, 1994)
Defense Information Systems Network (DISN) – A sub-element of the DII.
-
The DOD’s consolidated worldwide enterprise-level telecommunications infrastructure
that provides the end-to-end information transfer network for supporting military
operations. It is transparent to its users, facilitates the management of information
resources, and is responsive to national security and defense needs under all conditions in
the most efficient manner. (ASD [C3I] Memo, 1994)
-
An information transfer network with value-added services for supporting national
defense Command, Control, Communications, and Intelligence (C3I) decision support
requirements and Corporate Information Management (CIM) functional business areas.
As an information transfer utility, the DISN provides dedicated point-to-point, switched
voice and data, imagery, and video teleconferencing communications services. (CJCSI
6211.02, 1993)
Discretionary Access Control (DAC) – A means of restricting access to files based on the
identity and need-to-know of users and/or groups to which the file belongs.
Dual-homed Host – A general-purpose computer system that has at least two network
interfaces. Firewalls are commonly employed on dual-homed host machines. Also referred to as
dual-homed gateway.
Enclave – A network under the operational control and authority of a single organization with
the responsibility to define and implement security controls.
-
A group of one or more security domains that typically share close physical proximity
and that can have a clearly defined perimeter. Within DOD this could be the case of a
tenant activity located on a base controlled by another organization. The tenant activity
will be expected to have a firewall at the perimeter of its network “enclave,” and
additional internal firewalls to separate different security domains.
Enclave Perimeter – Those points where non-members of that enclave gain access to resources
and information within that enclave, or where members of the enclave, but resident within the
enclave, gain access to resources or information within that enclave.
64
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Event – An action directed at a target which is intended to result in a change of state (status) of
the target.
-
Any suspicious pre-assessed activity. (Army FM 100-6)
-
Any occurrence that changes the status of a managed object. It may be spontaneous or
planned, persistent or temporary, and may trigger other events or be triggered by other
events. (Military Handbook 1351- Network Management)
-
A combination of an “Action/Bypassing” taken against a “Target/Process.” (JTF CND
Taxonomy)
-
A discrete change of state or device. (JTF CND Taxonomy)
-
An action directed at a target, which is intended to result in a change (status) of the target.
(JTF CND Taxonomy)
-
Represents a logical linkage between an action and a specific target against which the
action is directed. (JTF CND Taxonomy)
Firewall – A system designed to defend against unauthorized access to or from a private
network. Firewalls can be implemented in hardware and software, or a combination of both.
-
A system or group of systems that enforces an access control policy between two
networks.
-
Similar to a router. Prime purpose is to inspect network traffic and prevent unauthorized
traffic from passing through.
-
Protects a network from an untrusted network.
Generic Proxy – A Transmission Control Protocol (TCP)-based gateway or forwarder that
permits the flow of TCP-based protocols. A generic proxy is often employed for TCP-based
protocols that are not supported by application-level proxy services. A risk assessment should be
performed for each TCP-based protocol that is handled via a generic proxy.
Hybrid Firewall – A hybrid firewall is a firewall that employs packet filtering and proxy
services. A hybrid firewall may also consist of one or more machines.
65
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Incident – An assessed event of attempted entry, unauthorized entry, and/or an information
attack on an Automated Information System (AIS). It includes unauthorized probing, browsing;
disruption, or denial of service; altered or destroyed input, processing, storage, or output of
information; or changes to system hardware, firmware, or software characteristics with or
without the user’s knowledge, instruction, or intent (e.g., malicious logic). (JIWG Proposed
Term)
-
An adverse event in an AIS and/or network of the threat of the occurrence of such an
event.
-
Not limited to cyber-based events, but also includes network operations, physical,
high-energy radio frequency, and other activity.
-
A full set of data describing the intrusion, the intruder, and the objective. (JTF CND
Taxonomy)
-
A group of intrusions that can be distinguished from other intrusions because of the
distinctiveness of the intruders, intrusions, objectives, sites, and timing. (JTF CND
Taxonomy)
Information Assurance (IA) – Information Operations (IO) that protect and defend information
and Information Systems (ISs) by ensuring their availability, integrity, authentication,
confidentiality, and non-repudiation. This includes providing for restoration of information
systems by incorporating protection, detection, and reaction capabilities. (DODD 3600.1)
Information Assurance Vulnerability Alert (IAVA) – Notification system developed by DISA
to provide the CINCs/Services/Agencies (C/S/A) with vulnerability notifications requiring C/S/A
feedback action acknowledging receipt and action taken back to DISA.
Information Systems (ISs) – The entire infrastructure, organization, personnel, and components
that collect, process, store, transmit, display, disseminate, and act on information. (Joint
Pub 6-0).
-
Includes all the building blocks—communications, operating environment middleware,
applications, and services—that provide information to any customer, throughout the
life-cycle of that information, while maintaining a system-wide level of quality.
-
Any equipment or interconnected system or subsystems used to acquire, store,
manipulate, manage, move, control, display, switch, transmit, or receive data or
information. This applies to ancillary equipment, software, firmware, and information
services including support service and related resources.
66
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Information Systems Security (INFOSEC) – The protection of Information Systems ISs)
against unauthorized access to or modification of information, whether in storage, processing, or
transit, and against denial of service to authorized users or the provision of service to
unauthorized users, including those measures necessary to detect, document, and counter such
threats. (NSTISSI 4009, 1992)
-
A composite of the means of protecting telecommunication systems and Automated
Information Systems (AISs) and the information they process. (FED-STD-1037B, 1991)
INFOSEC Assessment – A review of the INFOSEC posture of a specified, operational system
for the purpose of identifying potential vulnerabilities. Once identified, recommendation will be
provided for the elimination or mitigation of the vulnerability.
Infrastructure – Communications, data, applications, security, people, training, and other
support structures serving DOD’s location and worldwide information needs; the DII connects
DOD mission support, Command and Control (C2), and intelligence computers and users
through voice, data, imagery, video, and multimedia services and provides information
processing and value-added services to subscribers of the DISN. (Army FM 100-6).
-
The framework of interdependent networks and systems that provide a continual flow of
services. (DODD 5200.xx)
Intrusion – A series of steps taken by an intruder to achieve unauthorized result. (JTF CND
Taxonomy)
-
Any set of actions that attempts to compromise the integrity, confidentiality, or
availability of a resource. (HeadyLungerEtAl:90)
Intrusion Detection (Host-Based) – A host-based intrusion detection system is software that
monitors a system or application’s log files. It responds with an alarm or a countermeasure when
a user attempts to gain access to unauthorized data, files, or services.
Intrusion Detection (Network-Based) – A network-based intrusion detection system monitors
network traffic and responds with an alarm when it identifies a traffic pattern that it deems to be
either a scanning attempt or a denial of service or other attack.
Intrusion Detection System (IDS) – Attempts to detect an intruder breaking into a system.
Normally it will run constantly on a system, working away in the background, and only notifying
appropriate authorities when it detects something it considers suspicious or illegal.
67
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Levels of Robustness – Extend to which protective measures, techniques, and procedures must
be applied to ISs and networks based on risk, threat, vulnerability, system interconnectivity
considerations, and Information Assurance (IA) needs. Levels of robustness are:
1. Basic: IS and networks requiring implementation of standard minimum-security
countermeasures.
2. Medium: IS and networks requiring layering of additional safeguards above the standard
minimum-security countermeasures.
3. High: IS and networks requiring the most stringent protection and rigorous security
countermeasures.
Malicious Code – Code designed with a malicious intent to deny, destroy, modify, or impede
system configuration, programs, data files, or routines. Causes unwanted modification or
destruction of data. It can also steal data, allow unauthorized access, and exploit/damage an
Information System (IS) or entire network. Includes Trojan horses, bombs, worms, and viruses.
Malicious Logic – Hardware, software, or firmware intentionally included in an Information
System (IS) for an unauthorized purpose.
Mobile Code – Software modules obtained from remote systems, transferred across a network,
and then downloaded and executed on a local system (e.g., a workstation or laptop where the
web browser is executed), without explicit installation or initiation of execution by the recipient.
Monitoring – The act of listening, carrying out surveillance on, and/or recording the
actions/processes of one’s own system for the purpose of maintaining and improving security.
An analysis to discover system problems and to initiate corrections. To supervise, maintain, and
troubleshoot the network/system.
Packet Filtering Firewall – A system that permits or blocks network traffic from one network
to another based on information contained within packets (e.g., protocol header information).
Packet filtering may occur in a router, bridge, or host-based filtering system. Also referred to as
screening router. Advanced packet filtering systems are based on stateful packet inspection.
Perimeter Network – A network added between a protected network and an external network
that provides an additional layer of security. A perimeter network is also referred to as a DMZ
(De-Militarized Zone).
Physical Security – Those measures designed to safeguard personnel, prevent unauthorized
disclosure of classifiable information, and restrict access to sensitive equipment(s), installations,
material, and document control and to safeguard them against espionage, sabotage, and
damage/theft.
Port – A specific pathway for data and control information.
68
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Proxy Service – A program that deals with external servers on behalf of internal clients. Proxy
clients communicate with proxy servers, which relay approved client requests to proxy servers
and relay responses back to clients. Also referred to as proxy server, application-level gateway,
or forwarder.
Screening Router – A router used as a packet filtering firewall or system. A screening router or
packet filtering system routes packets between internal and external hosts. Screening routers
permit or block network traffic from one network to another based on information contained
within packets (e.g., protocol header information). Packet filtering may occur in a router, bridge,
or host-based filtering system. Also referred to as packet filtering system.
Security Domain – A group of networked components that share the same security policy.
Security Guard – A security guard is a set of mechanisms that mediate transfers of data or
information between environments operating at different security levels (e.g., Secret and
unclassified, U.S. and non-U.S.). A firewall is commonly used to protect one network from
another at the same security level whereas security guards provide controlled transfers of data or
information between networks operating at different security levels.
Security Incident – Any act or circumstance involving sensitive information in which there is a
deviation from the security regulations and/or requirements. (IMDS SFUG)
Sensitive WWW Applications – Those running on a limited-access web site with unclassified
information that has not been approved for release to the public.
Stateful Packet Inspection – Stateful packet inspection, a form of packet filtering, is considered
more advanced than packet filtering commonly supported by screening routers. Stateful packet
inspection firewalls maintain connection state information about original requests (e.g., port
number, source, or destination address) and compares the responses to determine whether the
packets should be accepted or rejected. Stateful packet inspection firewalls are also able to make
filtering decisions on Application or Upper Layer protocol traffic.
System Administrator (SA) – Responsible for the installation and maintenance of the system
providing effective IS utilization, adequate security parameters, and sound implementation of
established INFOSEC policy and procedures. (IMDS SFUG)
Trojan Horse – A set of computer instructions purposely hidden inside an actual, useful
program. This hidden function allows the unauthorized collection, falsification, or destruction of
data. The purpose is to create havoc on the computer of an unsuspecting user, ranging from hard
disk erasure to damage of program and data files. It is not self-triggering and does not
automatically run or reproduce itself.
69
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
Virtual Private Network (VPN) – A VPN is a physically disparate set of networks that share a
common security perimeter and policy through secured internetwork communication.
Vulnerability Assessment – Systematic examination of an Information System (IS) or product
to determine the adequacy of security measures, identify security deficiencies, provide data from
which to predict the effectiveness of proposed security measures, and confirm the adequacy of
such measures after implementation. (DODI 5200.4)
70
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
APPENDIX B: ACRONYMS
ACL
AIS
ANI
ASD
ATM
Access Control List
Automated Information System
Automatic Number Identification
Assistant Secretary of Defense
Asynchronous Transfer Mode
BMG
Border Gateway Protocol
C/S/A
C2
C3I
CERT
CIM
CINC
CIO
CJCSI
CND
COE
COI
COMSEC
CINCs/Services/Agencies
Command and Control
Command, Control, Communications, and Intelligence
Computer Emergency Response Team
Corporate Information Management
Commander-in-Chief
Chief Information Officer
Chairman, Joint Chiefs of Staff Instruction
Computer Network Defense
Common Operating Environment
Community of Interest
Communications Security
COTS
CUI
Commercial-Off-The Shelf
Controlled Unclassified Information
DAA
DAC
DBMS
DDoS
DECC
DECC-D
DES
DFAS
DID
DII
DISA
DISAI
DISN
DITSCAP
Designated Approving Authority
Discretionary Access Control
Database Management System
Distributed Denial of Service
Defense Enterprise Computing Center
Defense Enterprise Computing Center-Detachment
Data Encryption Standard
Defense Finance and Accounting Service
Defense-in-Depth
Defense Information Infrastructure
Defense Information Systems Agency
Defense Information Systems Agency Instruction
Defense Information Systems Network
DOD Information Technology Security Certification and Accreditation
Process
Defense Logistics Agency
Defense Message System
Demilitarized Zone
Domain Name Service
DNS Security Extension
Department of Defense
Department of Defense Directive
DLA
DMS
DMZ
DNS
DNSSEC
DOD
DODD
71
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
DODI
DoS
Department of Defense Instruction
Denial of Service
EMCB
Enclave Management Control Board
FA
FOUO
FSO
ftp
Firewall Administrator
For Official Use Only
Field Security Operations
File Transfer Protocol
GCCS
GCSS
GNOSC
GOTS
Global Command and Control System
Global Combat Support System
Global Network Operations and Security Center
Government-off-the Shelf
HTML
http
HTTPS
Hypertext Markup Language
Hyper Text Transfer Protocol
Hyper Text Transfer Protocol over Secure Sockets Layers
I&A
IA
IACB
IATO
IAVA
IDS
IG
IMAP
IMDS
INFOSEC
IO
IP
IPSEC
IRC
IS
ISO
ISP
ISSM
ISSO
ISSP
IT
ITM
Identification and Authentication
Information Assurance
Information Assurance Control Board
Interim Authority To Operate
Information Assurance Vulnerability Alert
Intrusion Detection System
Inspector General
Internet Mail Access Protocol
Intrusion and Misuse Deterrence System
Information Systems Security
Information Operations
Internet Protocol
Internet Protocol Security
Internet Relay Chat
Information System
International Standards Organization
Internet Service Provider
Information Systems Security Manager
Information Systems Security Officer
Information Systems Security Program
Information Technology
Information Technology Management
JIEO
JTF
JWICS
Joint Interoperability & Engineering Organization
Joint Task Force
Joint Worldwide Intelligence Communications System
KMP
Key Management Protocol
72
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
LAN
LCC
LDAP
Local Area Network
Local Control Center
Lightweight Directory Access Protocol
MD4
MD5
MSP
MVS
Message Digest 4
Message Digest 5
Message Send Protocol
Multiple Virtual Storage
NAT
NCS
NFS
NIC
NIPRNet
NNTP
NSA
NTP
Network Address Translation
National Communications System
Network File Server
Network Interface Card
Non-Classified Internet Protocol Router Network
Net News Transfer Protocol
National Security Agency
Network Time Protocol
OS
OSI
Operating System
Open System Interconnection
PAO
PC
PDA
PDD
PKI
PM
PMO
POC
POP
PPP
Public Affairs Office
Personal Computer
Personal Digital Assistant
Presidential Decision Directive
Public Key Infrastructure
Program Manager
Program Management Office
Point of Contact
Post Office Protocol
Point-to-Point Protocol
RAS
RCERT
RFC
RNOSC
RPC
Remote Access Server
Regional Computer Emergency Response Team
Request For Comments
Regional Network Operations and Security Center
Remote Procedure Call
SA
SABI
SCIF
SET
SFTF
SHA
SIPRNet
SMI
SMTP
SNMP
System Administrator
Secret and Below Interoperability
Sensitive Compartmented Information Facility
Secure Electronic Transaction
Simple File Transfer Protocol
Secure Hash Algorithm
Secret Internet Protocol Router Network
Security Management Infrastructure
Simple Mail Transfer Protocol
Simple Network Management Protocol
73
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
SRR
SSAA
SSH
SSL
STIG
Security Readiness Review
System Security Authorization Agreement
Secure Shell
Secure Socket Layers
Security Technical Implementation Guide
TCP
TFTP
Transmission Control Protocol
Trivial File Transfer Protocol
UDP
URL
User Datagram Protocol
Universal Resource Location
VCTS
VPN
Vulnerability Compliance and Tracking System
Virtual Private Network
WAN
WWW
Wide Area Network
World Wide Web
74
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
APPENDIX C. DOCUMENT REVISION REQUEST
DISA FIELD SECURITY OPERATIONS
ENCLAVE SECURITY TECHNICAL IMPLEMENTATION GUIDE
VERSION 1, RELEASE 1
Name: ________________________________ Title:__________________________________
Organization: __________________________ Site:___________________________________
Phone Number (DSN): __________________
Phone Number (Comm):___________________
Document Revision #:___________________
Document Date: _________________________
Use the space below to list the appropriate page and section numbers, and any specific comments
and/or revision requests. Provide justification for any requested changes. Please attach any
additional information to this form.
Please mail all correspondence to the following address:
DISA Field Security Operations
ATTN: STIG on Enclave Security Support
One Overcash Avenue, Building #1
Letterkenny Army Depot
Chambersburg, PA 17201-4122
E-mail address: stig_comments@ritchie.disa.mil
75
FOR OFFICIAL USE ONLY
Enclave STIG, V1R1
30 March 2001
Field Security Operations
Defense Information Systems Agency
This page is intentionally left blank.
76
FOR OFFICIAL USE ONLY