ENCLAVE SECURITY GUIDE - Maui Gateway
SECURITY TECHNICAL IMPLEMENTATION GUIDE
ON
ENCLAVE SECURITY
Version 1, Release 1
30 March 2001
[pic]
DISA
FIELD SECURITY OPERATIONS
This page is intentionally left blank.
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
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
APPENDIX B: ACRONYMS 71
APPENDIX C. DOCUMENT REVISION REQUEST 75
This page is intentionally left blank.
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 .
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.
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.
Figure 1.1. High-level Schematic of the Enclave Security Architecture
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 . 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.
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.
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.
This page is intentionally left blank.
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.
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 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.
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.
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 .)
• 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 or web site.
• 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.
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 or .
• 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.
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 or 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 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.
• 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 |SECURITY |DESCRIPTIONS |
|Open |Unencrypted |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. |
|Limited by Internet Domain (e.g., .mil,|Encrypted |Non-sensitive, not of general interest to the public although|
|.gov) or IP address | |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 specific, targeted audience. |
|Server Certificate Based |Encrypted |FOR OFFICIAL USE ONLY (FOUO) |
| |SSL | |
|User Certificate Based (Software) |Encrypted |FOR OFFICIAL USE ONLY (FOUO) and sensitive by aggregation. |
|Requires PKI |SSL | |
|User Certificate Based (Hardware) |Encrypted |FOR OFFICIAL USE ONLY (FOUO) and sensitive by aggregation |
|Requires PKI | |where extra security is required due to compilation. |
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 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.
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.
- 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.
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.
This page is intentionally left blank.
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.
2. This page is intentionally left blank.
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.
This page is intentionally left blank.
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.
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:
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.
This page is intentionally left blank.
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.
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.
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.
[pic]
Figure S1.1: Dual-homed Firewall Architecture
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 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.
[pic]
Figure S1.2: Screened Host Architecture
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.
[pic]
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.
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.
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.
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.
• 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.
• 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
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.
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.
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.
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.
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.
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)
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.
This page is intentionally left blank.
TABLE S 4.1: REQUIRED FILTERING RULES
|KEY TO TABLE ENTRIES |
|Allow |Without this service the system may not be fully functional. Allow, if required. No additional security controls necessary.|
|Deny |Possible source of entry for exploitation. If absolutely necessary, submit an extension request documenting rationale and |
| |alternate protection used. |
|Cond |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 |
|SERVICE |PORT |PROTOCOL |SECURITY |DESCRIPTION/NOTES |
| | | |IN-BOUND |OUT-BOUND | |
|TCP |1 |TCP |Deny |TCP Port Multiplexer. Rarely used. |
|Mux | | | | |
|Echo |7 |TCP;UDP |Deny |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 |
|Discard |9 |TCP;UDP |Deny |The dev/null of the Internet. Harmless. |
|Systat |11 |TCP |Deny |Occasionally connected to netstat, w, or ps; |
| | | | |a.k.a., user’s protocol. Returns active users.|
|Daytime |13 |TCP |Deny |Time of day. Time has been used in generation |
| | | | |of cryptographic keys. |
|Daytime |13 |UDP |Deny |Time of day. See above. CERT/CC 96-01 Denial |
| | | | |of Service. |
|Netstat |15 |TCP |Deny |Network status. Obsolete since 1994. |
|MSP, v2 |18 |TCP |Deny |Message Send Protocol. See RFC 1312 for |
| | | | |security considerations. |
|Chargen |19 |TCP;UDP |Deny |Character Generator. CERT/CC 96-01 Denial of |
| | | | |Service (UDP). |
|FTP-data |20 |TCP |Cond |Allow |Data channel for ftp. Hard to filter. |
| | | | | |Relevant CERT/CC Advisories: 97-27, 97-16, |
| | | | | |94-08, 94-07, 93-10, 93-06, 99-13, DOD-CERT |
| | | | | |1999-B-0003. |
|FTP |21 |TCP |Cond |Allow |ftp control channel. Allow only to your ftp |
| | | | | |server. See the CERT Advisories listed under |
| | | | | |ftp-data. |
|SSH |22 |TCP |Cond |Allow |Secure shell remote login protocol. |
|Telnet |23 |TCP |Deny |Cond |Telnet. Relevant CERT/CC Advisories: 95-14, |
| | | | | |95-03. Use destination IP filtering and strong|
| | | | | |authentication. |
| | | | | |NOTE: Telnet sends passwords in the clear. |
|SMTP |25 |TCP |Cond |Simple Mail Transfer Protocol. See CERT/CC |
| | | | |Advisory 95-05 for sendmail vulnerabilities. |
| | | | |Deny except for traffic to or from known mail |
| | | | |servers. |
|Time |37 |TCP;UDP |Deny |Time of day in machine-readable format. CERT/CC|
| | | | |96-01 Denial of Service (UDP). |
|Whois |43 |TCP |Deny |Allow |Internet user name directory service. |
|Login |49 |TCP |Deny |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 |53 |TCP/UDP |Cond |Allow |Domain Name Service. CERT/CC 99-14, DOD-CERT |
| | | | | |2000-A-01. |
|TACACS-DS |65 |TCP |Cond |TACACS-Database Service. Control access to |
| | | | |authenticate clients. |
|Bootp |67 |UDP |Deny |Bootstrap protocol server. Not required and |
| | | | |exploitable. |
|Bootpc |68 |UDP |Deny |Bootstrap protocol client. Not required and |
| | | | |exploitable. |
|TFTP |69 |UDP |Deny |Trivial File Transfer Protocol. See CERT/CC |
| | | | |Advisories 91-18, 91-19. |
|Gopher |70 |TCP |Deny |Gopher server. Not required and exploitable. |
| | | | |See CERT/CC Advisory 93-11 and DOD-CERT |
| | | | |Bulletin 93-21. |
|Finger |79 |TCP |Deny |Finger. See CERT/CC Advisory 93-04 and |
| | | | |DOD-CERT Bulletin 93-06. |
|HTTP |80 |TCP;UDP |Cond |Allow |Hyper Text Transfer Protocol. Deny incoming |
| | | | | |except to DMZ, proxy outgoing. DOD-CERT |
| | | | | |1999-A-10, 1999-A-9, |
| | | | | |1999-A-7,1999-B-1,1999-T-6,1999-T-3,CERT/CC |
| | | | | |2000-02. |
|Kerberos |88 |UDP |Cond |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. |
| | | | | |
|X.500 |102 |TCP |Cond |ISO-Directory. |
| | | | | |
|X.400 |103 |TCP |Cond |X.400 Electronic Mail. |
| | | | | |
|X.400-SND |104 |TCP |Cond |X.400 Electronic Mail. |
|POP-2 |109 |TCP |Deny |Post Office Protocol - Version 2. See CERT/CC |
| | | | |Advisory 98-11, 98-07, 97-09. |
|POP-3 |110 |TCP |Deny |Post Office Protocol - Version 3. See CERT/CC |
| | | | |Advisory 98-11, 98-07, 97-09. |
|SunRPC |111 |TCP;UDP |Deny |SUN Remote Procedure Call. See CERT/CC |
| | | | |Advisories 98-11, 95-17, 94-02, and DOD-CERT |
| | | | |Bulletins 98-08a, 95-49, 95-50. |
|Auth |113 |TCP |Cond |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. |
| | | | | |
|SFTP |115 |TCP |Deny |Simple ftp. |
|UUCP-path |117 |TCP |Deny |UUCP Path Service. See CERT/CC Advisory 92-06.|
|NNTP |119 |TCP |Cond |Network News Transfer Protocol (nntp). Access |
| | | | |should only be given through local nntp server |
| | | | |and proxied. CERT/CC 97-08, DOD-CERT 97-02. |
|NTP |123 |TCP;UDP |Cond |Allow |Network Time Protocol. Required by DMS and |
| | | | | |other systems. CERT/CC 96-01 Denial of Service |
| | | | | |(UDP). |
|Statsrv |133 |TCP |Deny |Statistics Service. See CERT/CC Advisory 97-26|
| | | | |and DOD-CERT Bulletin 96-12. |
|MS-RPC |135 |TCP;UDP |Deny |Cond |MS Remote Procedure Call. Required for MS |
| | | | | |Outlook, etc. Exploitable. |
|NetBIOS-NS |137 |TCP;UDP |Deny |Cond |NETBIOS Name Service. Exploitable. Brute |
| | | | | |forcible if improperly configured. Susceptible|
| | | | | |to denial of service. |
|NetBIOS-DGM |138 |TCP;UDP |Deny |Cond |NETBIOS Datagram Service. Exploitable. See |
| | | | | |NetBIOS-NS service comments. |
|NetBIOS-SSN |139 |TCP;UDP |Deny |Cond |NETBIOS Session Service. Exploitable. See |
| | | | | |NetBIOS-NS service comments. |
|IMAP2, 4 |143 |TCP |Deny |Internet Mail Access Protocol v2. CERT/CC |
| | | | |98-11, 98-07. |
| | | | | |
|SQL-Net |150 |TCP |Cond |SQL-NET. IP filter. |
|SNMP |161 |TCP;UDP |Deny |Cond |Simple Network Management Protocol. |
| | | | | |Exploitable. |
| | | | | | |
|SNMP-trap |162 |TCP;UDP |Cond |Deny |SNMPTRAP. Exploitable. |
|BGP |179 |TCP |Deny |Border Gateway Protocol. Not required for |
| | | | |enclave. |
|IRC |194 |TCP |Deny |Internet Relay Chat Protocol. See CERT/CC |
| | | | |Advisory 94-14 and DOD-CERT Bulletin 93-33. |
|IMAP3 |220 |TCP |Deny |Interactive Mail Access Protocol v3. See |
| | | | |CERT/CC Advisory 98-11, 98-07, 97-09. |
|SET |257 |TCP;UDP |Cond |Secure Electronic Transaction. Use IP |
| | | | |filtering. |
|LDAP |389 |TCP |Cond |Allow |Lightweight Directory Access Protocol. Use IP |
| | | | | |filtering and authentication. |
|HTTPS |443 |TCP;UDP |Cond |Allow |http protocol over TLS/SSL. DOD-CERT 1999-A-9. |
| | | | | |
|IsaKMP |500 |UDP |Cond |Key management protocol. |
| | | | | |
|Rexec |512 |TCP |Deny |Remote process execution. |
|Rlogin |13 |TCP |Deny |Remote login. See CERT/CC Advisories 97-06, |
| | | | |95-15, and 94-09. |
|Rwho |513 |UDP |Deny |Remote who command. Maintains database of who |
| | | | |is logged in to machines on a local network. |
|Rsh |514 |TCP |Deny |Similar to exec, but automatic authentication |
| | | | |is performed for login server. |
|Syslog |514 |UDP |Deny |Can gain access to audit logs. Exploitable. |
| | | | |See CERT/CC Advisory 95-13. |
|Printer |515 |TCP |Deny |Line printer spooler. See CERT/CC Advisories |
| | | | |97-19, 95-15. |
|Talk |517 |UDP |Deny |Actual talk protocol uses random TCP ports. |
| | | | |See CERT/CC Advisory 97-04 and DOD-CERT |
| | | | |Bulletin 97-07. |
| | | | | |
|Ntalk |518 |UDP |Deny |Same as talk. |
|RIP |520 |UDP |Deny |Outsiders can gain access to routing tables. |
| | | | |Exploitable. |
|UUCP |540 |TCP |Deny |Historically a dangerous service, and mostly |
| | | | |obsolete on the Internet. See CERT/CC Advisory|
| | | | |92-06. |
|Klogin |543 |TCP;UDP |Deny |See CERT/CC Advisory 97-06. |
|LDAPS |636 |TCP;UDP |Cond |Allow |LDAP protocol over TLS/SSL (was sldap). |
|Flexlm |744 |TCP;UDP |Deny |Flexible License Manager. See CERT/CC Advisory|
| | | | |97-01. |
|Kerberos- admin |749 |TCP;UDP |Deny |Cond |Kerberos administration. |
|SecureID |1024 |TCP;UDP |Cond |Secure Identification for remote access |
| | | | |authentication. |
|PDA |1333 |TCP |Deny |Cond |PerDiemAmazing. Travel orders and vouchers. |
|Lotus |1352 |TCP;UDP |Cond |Lotus Notes. IP filtering based on client and |
|Notes | | | |server location. |
|ICA |1494 |TCP |Cond |Citrix Independent Computing Architecture. |
| | | | | |
|SQL-Net |1521 |TCP |Cond |Oracle SQL-Net. |
|NFS |2049 |TCP;UDP |Deny |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. |
| | | | | | |
|Calendar |5730 |TCP |Cond |Deny |Netscape calendar. |
|X11 |6000-6020 |TCP |Deny |Block the entire range of X11 ports, if |
| | | | |possible. |
|IRC |6667 |TCP |Deny |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. |
|PNM |7070 |TCP |Cond |Deny |Streaming audio. Also referred to as Real |
| | | | | |Audio. |
| | | | | |
|DMS X.500 |17003 |TCP |Cond |X.500 for DMS. |
NOTE: All ICMP traffic should be denied.
This page is intentionally left blank.
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.).
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).
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:
This page is intentionally left blank.
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:
This page is intentionally left blank.
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)
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.
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: NISTIR-4659)
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).
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.
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.
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.
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.
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.
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.
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)
APPENDIX B: ACRONYMS
|ACL |Access Control List |
|AIS |Automated Information System |
|ANI |Automatic Number Identification |
|ASD |Assistant Secretary of Defense |
|ATM |Asynchronous Transfer Mode |
| | |
|BMG |Border Gateway Protocol |
| | |
|C/S/A |CINCs/Services/Agencies |
|C2 |Command and Control |
|C3I |Command, Control, Communications, and Intelligence |
|CERT |Computer Emergency Response Team |
|CIM |Corporate Information Management |
|CINC |Commander-in-Chief |
|CIO |Chief Information Officer |
|CJCSI |Chairman, Joint Chiefs of Staff Instruction |
|CND |Computer Network Defense |
|COE |Common Operating Environment |
|COI |Community of Interest |
|COMSEC |Communications Security |
|COTS |Commercial-Off-The Shelf |
|CUI |Controlled Unclassified Information |
| | |
|DAA |Designated Approving Authority |
|DAC |Discretionary Access Control |
|DBMS |Database Management System |
|DDoS |Distributed Denial of Service |
|DECC |Defense Enterprise Computing Center |
|DECC-D |Defense Enterprise Computing Center-Detachment |
|DES |Data Encryption Standard |
|DFAS |Defense Finance and Accounting Service |
|DID |Defense-in-Depth |
|DII |Defense Information Infrastructure |
|DISA |Defense Information Systems Agency |
|DISAI |Defense Information Systems Agency Instruction |
|DISN |Defense Information Systems Network |
|DITSCAP |DOD Information Technology Security Certification and Accreditation Process |
|DLA |Defense Logistics Agency |
|DMS |Defense Message System |
|DMZ |Demilitarized Zone |
|DNS |Domain Name Service |
|DNSSEC |DNS Security Extension |
|DOD |Department of Defense |
|DODD |Department of Defense Directive |
|DODI |Department of Defense Instruction |
|DoS |Denial of Service |
| | |
|EMCB |Enclave Management Control Board |
| | |
|FA |Firewall Administrator |
|FOUO |For Official Use Only |
|FSO |Field Security Operations |
|ftp |File Transfer Protocol |
| | |
|GCCS |Global Command and Control System |
|GCSS |Global Combat Support System |
|GNOSC |Global Network Operations and Security Center |
|GOTS |Government-off-the Shelf |
| | |
|HTML |Hypertext Markup Language |
|http |Hyper Text Transfer Protocol |
|HTTPS |Hyper Text Transfer Protocol over Secure Sockets Layers |
| | |
|I&A |Identification and Authentication |
|IA |Information Assurance |
|IACB |Information Assurance Control Board |
|IATO |Interim Authority To Operate |
|IAVA |Information Assurance Vulnerability Alert |
|IDS |Intrusion Detection System |
|IG |Inspector General |
|IMAP |Internet Mail Access Protocol |
|IMDS |Intrusion and Misuse Deterrence System |
|INFOSEC |Information Systems Security |
|IO |Information Operations |
|IP |Internet Protocol |
|IPSEC |Internet Protocol Security |
|IRC |Internet Relay Chat |
|IS |Information System |
|ISO |International Standards Organization |
|ISP |Internet Service Provider |
|ISSM |Information Systems Security Manager |
|ISSO |Information Systems Security Officer |
|ISSP |Information Systems Security Program |
|IT |Information Technology |
|ITM |Information Technology Management |
| | |
|JIEO |Joint Interoperability & Engineering Organization |
|JTF |Joint Task Force |
|JWICS |Joint Worldwide Intelligence Communications System |
| | |
|KMP |Key Management Protocol |
| | |
|LAN |Local Area Network |
|LCC |Local Control Center |
|LDAP |Lightweight Directory Access Protocol |
| | |
|MD4 |Message Digest 4 |
|MD5 |Message Digest 5 |
|MSP |Message Send Protocol |
|MVS |Multiple Virtual Storage |
| | |
|NAT |Network Address Translation |
|NCS |National Communications System |
|NFS |Network File Server |
|NIC |Network Interface Card |
|NIPRNet |Non-Classified Internet Protocol Router Network |
|NNTP |Net News Transfer Protocol |
|NSA |National Security Agency |
|NTP |Network Time Protocol |
| | |
|OS |Operating System |
|OSI |Open System Interconnection |
| | |
|PAO |Public Affairs Office |
|PC |Personal Computer |
|PDA |Personal Digital Assistant |
|PDD |Presidential Decision Directive |
|PKI |Public Key Infrastructure |
|PM |Program Manager |
|PMO |Program Management Office |
|POC |Point of Contact |
|POP |Post Office Protocol |
|PPP |Point-to-Point Protocol |
| | |
|RAS |Remote Access Server |
|RCERT |Regional Computer Emergency Response Team |
|RFC |Request For Comments |
|RNOSC |Regional Network Operations and Security Center |
|RPC |Remote Procedure Call |
| | |
|SA |System Administrator |
|SABI |Secret and Below Interoperability |
|SCIF |Sensitive Compartmented Information Facility |
|SET |Secure Electronic Transaction |
|SFTF |Simple File Transfer Protocol |
|SHA |Secure Hash Algorithm |
|SIPRNet |Secret Internet Protocol Router Network |
|SMI |Security Management Infrastructure |
|SMTP |Simple Mail Transfer Protocol |
|SNMP |Simple Network Management Protocol |
|SRR |Security Readiness Review |
|SSAA |System Security Authorization Agreement |
|SSH |Secure Shell |
|SSL |Secure Socket Layers |
|STIG |Security Technical Implementation Guide |
| | |
|TCP |Transmission Control Protocol |
|TFTP |Trivial File Transfer Protocol |
| | |
|UDP |User Datagram Protocol |
|URL |Universal Resource Location |
| | |
|VCTS |Vulnerability Compliance and Tracking System |
|VPN |Virtual Private Network |
| | |
|WAN |Wide Area Network |
|WWW |World Wide Web |
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
This page is intentionally left blank.
-----------------------
Security
Domain
LAN
Security
Domain
LAN
DMZ Server
Firewall
Network IDS
DII
Wide Area
Network
Router
Perimeter
Switch
Router or
Security
Domain
LAN
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
Related searches
- security classification guide army
- security classification guide dod
- a security classification guide scg is
- maui vanilla plantation
- dod security classification guide handbook
- security classification guide training
- what information do security classification guide scg
- free security study guide download
- security free study guide pdf
- security study guide 501
- security plus study guide 501
- comptia security study guide pdf