SECURITY TECHNICAL IMPLEMENTATION GUIDE ON ENCLAVE SECURITY

blackstartΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

547 εμφανίσεις



FOR OFFICIAL USE ONLY




SECURITY TECHNICAL IMPLEMENTATION GUIDE


ON


ENCLAVE SECURITY



Version 1, Release 1



30 March 2001










DISA

FIELD SECURITY OPERATIONS

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

ii

This page is intentionally left blank.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

iii

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 Secur
ity

................................
................................
................................
.
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) S
ecurity

................................
................................
............
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) Applica
tions

................................
...............................
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. SOFT
WARE 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

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

iv

6. DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION AND EXTENSION
REQUIREMENTS

................................
................................
................................
.........................
29

6.1 Guidance

................................
................................
................................
...........................
29

6.2 Enclave Security Implementation Descriptio
n Process

................................
....................
29

6.3 Enclave Security Extension Process

................................
................................
.................
30

SUPPLEMENT 1: ENCLAVE FIREWALL GUIDANCE

................................
..........................
31

S 1 Purpose

................................
................................
................................
.............................
31

S 2 Firewall Implem
entation 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 Identificatio
n 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 Translatio
n (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 IMPL
EMENTATION DESCRIPTION
REPORT

................................
................................
................................
................................
..
55

EXAMPLE 2: DISA ENCLAVE SECURITY EXTENSION REQUEST

............................
57

EXAMPLE 3: MOBILE CODE TECHNOLOGY RISK EXTENSION REQUEST

............
59

APPENDIX A. GLOS
SARY OF TERMS

................................
................................
...................
61

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

v

APPENDIX B: ACRONYMS

................................
................................
................................
......
71

APPENDIX C. DOCUMENT REVISION REQUEST

................................
................................
75


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

vi

This page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

1

1. INTRODUCTION

1.1 Background

This Se
curity 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 en
sure 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 sensitivi
ty 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 Intern
et 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). T
his 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 D
efinitions

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 acr
oss 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 poin
ts 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

2

Enclaves can be broken down into
Security Domains

or
Communities of Interest (COIs)
.
This STIG will be based on the data, u
sers, 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 d
ifferent 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 sys
tem at a LAN
to LAN interface, in addition to the firewall separating the LANs from the WAN at the enclave
perimeter.































Figure 1.
1
. High
-
level Schematic of the Enclave Security Architecture


Security

Domain

LAN

Router or

Switch

Perimeter

Router

DII

Wide Area

Network

Network IDS

Firewall

DMZ Server

Security

Domain

LAN

Security

Domain

LAN

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

3

1.3 Writ
ing 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 “
sh
ould
” 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 recommendati
ons 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
us
e 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
.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

4

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 fo
r 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, sc
ripts, 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 Fiel
d 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 w
ill 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

5

1.6 INFOCON

The Information Operations Condition (INFOCON) recommends act
ions 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 responsibilit
y 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 pr
ocedures) 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.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

6

Thi
s page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

7

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 certificati
on 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

E
nclave 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 implem
ent 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 gene
ral, 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 secur
ity 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 o
r 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 a
s 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 (ST
IGs) 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.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

8

2.2.1 Enclave Perimeter Network Intr
usion 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 Perim
eter.




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 an
y 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 appro
ve
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 secu
rity 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 no
t 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 addr
ess 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

9

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 functio
ns, 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 an
d 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
.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

10

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 I
DS 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
f
or 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 mak
ing 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 ba
sis.


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, Nort
on 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
attachme
nts, 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.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

11




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 intrude
rs. 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 o
n 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 pro
cessing 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 m
echanisms 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

12

2.4.1 Operating System (OS) S
ecurity

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 s
ecurity 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 testi
ng 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 a
larms.




The site will report significant incidents to the site’s RCERT.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

13

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 possib
le 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.




A
ll 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 detecti
on 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 empl
oyees 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 service
s 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 att
ackers. 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 r
equirements. 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 us
ed.




Public servers, approved by the Public Affairs Office (PAO), will be isolated on a separate
LAN segment (DMZ) from all private DISA systems.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

14




Private web servers wil
l 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
sens
itive by aggregation.


TABLE 2.
1
. MINIMUM WEB SERVER AUTHENTICATION REQUIREMENTS


CONTROLS

SECURITY

DESCRIPTIONS

Open

Unencrypted

Non
-
sensitive, of general interest to the
public, cleared and authorized for public
release for whic
h worldwide
dissemination poses limited risk for
DOD or DOD personnel, even if
aggregated with other information
reasonably expected to be in the public
domain.

Limited by Internet
Domain (e.g.,
.mil
,
.gov
)
or IP address

Encrypted

Non
-
sensitive, not of ge
neral interest to
the public although approved and
authorized for public release (to include
foreign nationals), and intended for
DOD or other specifically targeted
audience.

Limited By User ID and
Password

Encrypted

Non
-
sensitive, but limited to a specif
ic,
targeted audience.

Server Certificate Based

Encrypted

SSL

FOR OFFICIAL USE ONLY (FOUO)

User Certificate Based
(Software) Requires PKI

Encrypted

SSL

FOR OFFICIAL USE ONLY (FOUO)
and sensitive by aggregation.

User Certificate Based
(Hardware) Requires

PKI

Encrypted

FOR OFFICIAL USE ONLY (FOUO)
and sensitive by aggregation where extra
security is required due to compilation.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

15

2.5.2 E
-
mail Systems

Government
-
owned, Defense Message System (DMS) approved e
-
mail systems will be used for
authorized, uncla
ssified 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 app
roved
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 w
ith 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 co
de 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 i
s
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 tr
usted 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 applica
tions 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) requi
red by DODI 5200.40. All DISA activities are
strongly encouraged to configure all end systems to disallow the execution of
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

16

downloaded Category 1 mobile code. Category 1 mobile code should also be blocked at
the enclave boundary.


-

Category 2 (
Java, MS Off
ice 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 kno
wn 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 tr
usted 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 origina
ting 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 me
et 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 availa
ble 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 als
o 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 e
xplicitly 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 peri
meter.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

17

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 poli
cy 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 Datab
ase 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 si
gnificant 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 wit
h 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 B
IND 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

18

-

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 D
NS 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 potent
ial 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
commun
ications 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 ser
vices
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
-
ma
il 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

19

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 u
pon 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
.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

20

This page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

21

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 vulnera
bility 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 vulner
ability 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 Encl
ave Security Architecture.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

22

This page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

23

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 hole
s 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 databas
e.




All DISA assets that support enclave protection will be registered and tracked for
compliance in VCTS.

Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

24

This page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

25

5. SOFTWARE DEVELOPMENT GUIDANCE

5.1 Purpose

The following sections outline basic guidance for software dev
elopers 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. Addi
tionally, 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 applic
ations 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
en
vironment. 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 applic
ation 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 vulnerabilitie
s. 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

26

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 numb
ers, 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 fea
tures 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 Refer
ences

The documents referenced in the following sections provide detailed guidelines for integration of
security applications that need access through a DISA firewall:


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

27

5.7.1 Microsoft Windows NT OS

Detailed security guidance for developing software to o
perate 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 secur
ity 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.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

28

This page is intentionally left blank.
Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

29

6. DISA ENCLAVE SECURITY IMPLEMENTATION DESCRIPTION A
ND
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
-
manage
d 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 insta
lling 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
-
m
anaged 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 com
puter 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 har
dware 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 ENC
LAVE SECURITY IMPLEMENTATION DESCRIPTION REPORT (see
Example 1

in
Supplement 1
).
Section 6.3, Enclave Security Extension Process
, describes the
extension process.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

30

The CIO will perform an initial review of the report for completeness. If the CIO determi
nes
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 Extensi
on 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 reques
t 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
appropria
te 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, w
ith
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 w
ill 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, inclu
ding tracking and archiving
the request.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

31

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 p
olicy 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 t
hese 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 g
ateway can be reached from both sides, but
traffic cannot directly flow across it.



Figure S1.1: Dual
-
homed Firewall Architecture


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

32

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
-
home
d 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 in
ternal
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 wil
l 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 tw
o 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 an
d address translation functions provided by a full
-
blown 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.



Figure S1.2: Screened Host Architecture



Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

33

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 n
etwork 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.



Figure S1.3: Dual
-
homed with Scr
eened 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 Archite
cture. 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
ex
ternal 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 A
rchitecture 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 b
e implemented in a parallel configuration between the internal and external
networks.


Enclave STIG, V1R1

Field Security Operations

30 March 2001

Defense Information Systems Agency



FOR OFFICIAL USE ONLY

34

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 fa
ctors, 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 con
nections.


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 inte
rconnecting 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