Military reference books and manuals (2009-2023, Volume 7)

NETWORK OPERATIONS SYSTEMS AND TOOLS

Maintains an up-to-date archive by automatically identifying and storing

changes to configuration files.

Supports configuration file searching to simplify locating specific device

configurations and configuration attributes.

Identifies differences between the running and startup configurations.

Has the ability to choose a device and its version of configuration and

download it to the device from the configuration archive application.

NetConfig—

Allows configuration changes to be performed against multiple switches or

routers in the network; changes can be downloaded immediately or run as

scheduled operations.

Provides flexibility in pushing command line interface changes out to the

network via user-defined templates that are published to an authorized user

or group of users for execution.

Has the ability for operators to specify username and password for devices

selected for the job and during the job creation (functionality also available

in ConfigEditor and NetShow).

ConfigEditor provides a powerful Web-based editing facility for modifying and downloading

configuration changes.

NetShow provides a simplified Web-based show command interface, allowing show commands

to be run against multiple switches or routers to enhance and simplify network troubleshooting.

B-12. The software image manager simplifies and speeds up software image analysis and deployment of

software updates to the Cisco routers and switches through wizard-assisted planning, scheduling,

downloading, and monitoring of software updates. The software image manager automates the many time-

consuming steps required to upgrade software images while reducing the error-prone complexities of the

upgrade process.

B-13. The change audit displays comprehensive reports of software, hardware, and configuration changes.

Change audit is a central point where users can view network changes. Summary information is easily

displayed, and shows the types of changes that are made. The information indicates who made the changes,

when they were made, and if the changes were made from a telnet, console command-line interface, or a

CiscoWorks application. Further, the nature of the changes is identified quickly through detailed reports

(cards added or removed, memory changes, configuration changes, and so on).

B-14. The syslog analyzer isolates network error conditions and suggests probable causes. Syslog analyzer

filters syslog messages logged by Cisco switches, routers, access servers, and Cisco Internet operating

system firewalls, thus displaying explanations of probable causes and recommended actions. It leverages

embedded Cisco Internet operating system technology to provide detailed device information.

B-15. The availability manager allows you to drill down on a particular device to view historical details

about its response time, availability, reloads, protocols, and interface status.

B-16. CiscoView 5.3 is a Web-based device management application providing dynamic status, monitoring,

and configuration information for Cisco internetworking products. CiscoView displays a physical view of a

device chassis, with color-coding of modules and ports for visual status. Configuration capabilities allow

comprehensive changes to devices given that requisite security privileges are granted.

B-17. WhatsUp Gold is a simple network management tool that enables the network manager to map and

monitor the LAN and WAN. It also provides electronic notification and reporting of network changes, an

interactive Web interface for remote viewing and administration, and a suite of network tools to help

diagnose network problems.

B-18. The Denika Multi-Router Traffic Grapher v3.0.1.210 monitors the traffic load on network links and

generates HTML pages containing graphical representations of live network traffic. Multi-Router Traffic

19 November 2008

FM 6-02.71

B-7

FOR OFFICIAL USE ONLY

Appendix B

Grapher uses Simple Network Management Protocol to read router traffic counters log traffic data, and

create traffic graphs for the monitored network connection.

B-19. The Enhanced Position Location Reporting System network manager (ENM) plans, configures,

manages, and monitors the EPLRS network. It is the programmed replacement for the net control station—

EPLRS, which is currently fielded to selected units in the Army. The ENM consists of two primary

functions:

EPLRS network planner: It is hosted on a laptop and is used to plan the EPLRS network, and

provide key generation, platform configuration, and radio set configuration and reconfiguration.

It is also used to initiate the timing master.

EPLRS network monitor: It is hosted on a laptop located in G-6 or S-6 staff section. It provides

configuration and cryptographic key files to forward deployed radios. It also provides monitoring

and fault isolation of the ELPRS network.

B-20. The primary function of the ISYSCON (V) 4 is to configure and initialize network devices (locally or

remotely) and disseminate configuration files to other ISYSCON (V) 4 in the network. The system will also

monitor and perform fault management of the Army Battle Command System (ABCS) devices connected to

the Tactical Internet, manage TOC and command post LANs, and monitor the status of the EPLRS and

Blue Force Tracking (BFT) SA networks. It also performs critical changes to the network configuration and

ensures distribution throughout the network. The ISYSCON (V) 4 package includes the Tactical Internet

Management System, Force XXI Battle Command Brigade and Below (FBCB2) software 6.4.3, and Open

Office 1.0.

B-21. The Tactical Information Management System is the backbone software package for the ISYSCON

(V) 4. It provides the capability to plan, configure, and initialize network devices. It provides the graphical

user interface that allows access to all other programs residing on the systems (ENM, WhatsUp Gold, etc.).

It also provides the capability to perform unit task reorganization, which plans and implements changes to

the initial network configuration for the Tactical Internet.

B-22. The FBCB2 6.4.3 software operates in the backg2round of the ISYSCON (V) 4 enabling EPLRS and

BFT the capability to provide SA and networks status monitoring. It allows the ISYSCON (V) 4 to function

as the primary link between the FBCB2 centered Tactical Internet and other ABCS.

B-23. The Open Office 1.0 software enables the operator to create, edit, and print operational data reports.

These reports detail the status and health of the LAN, FBCB2, or BFT SA networks. It includes tools

typically found in office suite software bundles to include WRITER, CALC, IMPRESS, and DRAW.

WRITER is a tool for creating documents, reports, newsletters, and brochures. You can integrate images

and charts in documents, create letters, and create and publish Web content. CALC is a spreadsheet that can

calculate and analyze data. IMPRESS is the multi-media presentation tool with special effects, animation,

and high-impact drawing abilities. DRAW will produce everything from simple diagrams to dynamic 3D

illustrations and special effects.

ISYSCON (V) 4 LITE

B-24. ISYSCON (V) 4 Lite provides the user with the capability to manually configure network devices and

to monitor the local TOC LAN.

B-25. The Trivial File Transfer Protocol server allows configurations performed on the (V) 4 Lite to be

transferred to the network devices through the LAN or a local connection.

B-26. WhatsUp Gold is a simple network management tool that enables the network manager to map and

monitor the LAN and WAN. It also provides electronic notification and reporting of network changes, an

interactive Web interface for remote viewing and administration, and a suite of network tools to help

diagnose network problems.

B-8

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

NETWORK OPERATIONS SYSTEMS AND TOOLS

ISYSCON (V) 1 AND 2

B-27. ISYSCON automates the coordination requirements for performing the essential functions of network

management. It incorporates common hardware software workstations into a LAN that uses the Area

Common User System to link all other ISYSCON shelters. It has Single-Channel Ground and Airborne

Radio System (SINCGARS), EPLRS, and high frequency radio communications capabilities for use as the

transmission means of linking ISYSCON elements. It supports planning, controlling, monitoring, and

managing of tactical networks and communications assets, including tropospheric scatter radio, combat net

radio, mobile subscriber equipment, tri-service tactical, SATCOM, high-speed data network, and

commercial capabilities.

B-28. ISYSCON interfaces with other ISYSCONs operating on the same software version, with the

Automated Communications Engineering Software, and will soon be interoperable with the Joint Network

Management System. ISYSCON uses a standard database for frequency assignment function and Network

Planning and Engineering. It performs WAN management and will allow a constant view of the network.

ISYSCON stores and uses information regarding non-signal corps and non-communication emitters in

managing the frequency assignment function. Its system management capabilities allow for the monitoring

and managing of the communication network status and performance. ISYSCON provides a complete view

of the battlefield WAN configuration and operational status in order to determine whether communication

assets meet requirements and how best to employ for continuing operations. ISYSCON also supports the

networks of other Armed Services and commercial systems.

Network Planning and Engineering

B-29. The network planning and engineering module uses new data to initiate development of new or

modified mobile subscriber equipment network lay-downs to support the commander’s directives. Once the

lay-downs and plans are entered into the database, the frequency assignment function provides final

engineering support of frequencies. The result of the network planning and engineering management,

frequency assignment function, and COMSEC management processes becomes the basis for the

communications plan. The network planning and engineering functions include data management

(organization, task force, and equipment), link and site analysis, and asset planning. These functions

facilitate the planning, design, and employment of communications networks. Considering terrain and

tactical restrictions, this optimizes the placement of limited resources against subscriber requirements.

Detailed Planning and Engineering Module

B-30. The detailed planning and engineering module consists of hardware components and software

applications. The hardware consists of a Tadpole V1 UNIX Laptop UltraSPARC IIi and the software

consists primarily of the GNOME v2.0 application and the StarOffice v6.0 application suite.

Battlefield Spectrum Managment Module v 3.4

B-31. The battlefield spectrum management module manages frequency allotment, develops frequency

assignments for tactical transmitters, and distributes those plans. It performs interference analysis and de-

conflictions of those assigned frequencies.

Local Area Network and Wide Area Network Management Module

B-32. The LAN and WAN management module manages devices and events. It provides a graphical, near

real-time representation of the WAN. The planned network selected for management is displayed with or

without a map backg2round. Event detection, translation, filtration, and dissemination activities control the

presentation of the display. The network management center software has been ported on ISYSCON to

perform comprehensive monitoring and centralized troubleshooting capabilities for the tactical packet

network.

19 November 2008

FM 6-02.71

B-9

FOR OFFICIAL USE ONLY

Appendix B

Mission Plan Management

B-33. The mission plan management module is where instructions and orders are developed. The module

plans the required implementation of networks and systems, and prepares the command, control,

communications, and computer operations annex to the OPORD or FRAGO, as required. The instructions

(communications service orders) are transmitted to the responsible ISYSCONs for implementation. During

pre-deployment, the communications service orders are printed and issued as team packets by the respective

unit.

B-34. Each individual ISYSCON directs its networks to implement the communications service orders, and

the communications network is established or modified. Upon network establishment, status reports are sent

by users or automatically retrieved from communications terminals, switches, or other equipment back to

the ISYSCON. These status reports that contain configuration, fault, and performance data are then

provided to the WAN management function. The mission plan management module—

Obtains the current network status.

Synchronizes all network personnel assets to support operations.

Develops deployment contingency plans.

Generates and distributes deployment and redeployment plans and orders.

Manages redeployment of network assets.

Includes software modules for COOP.

Plans operations generation, distribution, reconfiguration, and time synchronization.

System Administration

B-35. The system administrator can initialize, configure, monitor, and shut down the ISYSCON node.

These activities are categorized into administration of the node hardware components, communications with

the WAN, and administration of the data that is resident in the ISYSCON node. The system administrator

assigns each AOR an ISYSCON node as its primary node. It then configures ISYSCON to support the

requirements of the AOR.

Wide Area Network Manager

B-36. A WAN manager platform is present within each security domain (NIPR and SIPR). The WAN

manager provides monitoring and control capabilities that report on the condition of the routers and

network components. In addition, the WAN manager platform provides the capability to build and save

Cisco device configurations (router and firewall) based upon mission specific criteria. Remote management

capability exists using a standard Web browser. The JNN WAN manager platform is a Panasonic

Toughbook laptop computer with the following software installed: Hewlett Packard OpenView Network

Node Manager, Ciscoworks for Small Network Management Systems, Resource Manager Essentials 3.3,

and CiscoView 5.3 components.

Hewlett Packard OpenView

B-37. The Hewlett Packard OpenView network node manger collects topology, trend, and event data that

are used to troubleshoot report on, and analyze the network. It gives the network managers the information

they need to ensure network availability and reliability.

B-38. Most devices within the JNN can be remotely accessed via the terminal server or KVM switch, with

the use of a Web browser or HyperTerminal connection. There are some devices that cannot be accessed

via the aforementioned means and require a manual man or machine interface. These devices include:

SIPR and NIPR 100BTX/FX converters and hubs.

Quad-MUX.

All patch panels.

KIV-19.

B-10

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

NETWORK OPERATIONS SYSTEMS AND TOOLS

KIV-7HS.

INFORMATION ASSURANCE AND COMPUTER NETWORK

DEFENSE

B-39. The systems addressed in this section are designed to provide IA/CND functions to the force.

INTRUSION DETECTION SYSTEMS

B-40. Internet Security Systems RealSecure IDS components monitor network and server activity for

malicious intent or activity such as denial of service attacks, unauthorized access attempts, and pre-attack

reconnaissance. When Internet Security Systems RealSecure IDS detects such activity, it can respond by

recording the event, notifying the network administrator, terminating the attack, reconfiguring the firewall,

and suspending or disabling an account.

ELECTRONIC KEY MANAGEMENT SYSTEM

B-41. Electronic Key Management System (EKMS) is a four tiered system. EKMS defines an overall key

management system in support of the GIG. EKMS provides the capability for generation, distribution,

destruction, and management of electronic key, as well as management of physical key and non-key

COMSEC related items. EKMS provides functions that allow COMSEC account registration, privilege

management, ordering, distribution, and accounting to direct the management and distribution of physical

and electronic COMSEC materiel for the services. Other key features are:

The Local Management Device/Key Processor (LMD/KP) supports the functions performed by

the COMSEC Account Manager at the COMSEC account level of the EKMS structure. The

LMD/KP is the workstation component at the COMSEC account level. It automates and

computerizes many of the COMSEC procedures that have traditionally been performed manually

within a COMSEC account. is the of the Electronic Key Management The Local Management

Device/Key Processor provides the system management and audit support required to manage a

COMSEC account.

Local COMSEC Management Software (LCMS) is the NSA developed software that resides on

an LMD/KP. It provides ordering, generation, distribution, and accounting for keying material

(electronic or physical) and other associated COMSEC material. .

Automated Communications Engineering Software (ACES) is a Windows NT-based software

package loaded on a Panasonic CF-27 laptop. It is a planning and management tool that provides

the load sets (keying materiel, hop sets) for single-channel radio systems. ACES automates the

configuration of cryptographic devices and plans, manages, validates, generates, and distributes

products associated with signal operating instructions and electronic protection.

The Army Key Management System is an automated system designed for use in the tactical

environments. It integrates the functions of COMSEC key management, control and distribution

frequency management and signal operating instructions preparation.

ARMY INFORMATION SYSTEM

B-42. The Army information system provides firewall capabilities for the different ABCS platforms

residing on the LAN. The Army information system hosts the common service capabilities for the ABCS

6.4 capable systems on the LAN. It primarily serves as a publish-and-subscribe server, coordinating the

information produced by individual ABCS enabled platforms. Through a global positioning systems

connection, it provides timing to the ABCSs resident on the LAN.

NORTON FIREWALL MANAGEMENT

B-43. Whether an organization deploys a single gateway or thousands, Symantec Enterprise Firewall offers

a range of management tools to help reduce on-going operating costs. It provides scalable and centralized

19 November 2008

FM 6-02.71

B-11

FOR OFFICIAL USE ONLY

Appendix B

management. Symantec Enterprise Firewall can be managed by the standalone, secure, Web-based Security

Gateway Management Interface. For advanced management capabilities, the optional Symantec Advanced

Manager and Symantec Event Manager for Security Gateway plugs in to the Symantec management

console, therefore providing centralized policy CM, logging, alerting, and reporting for all security

functions. The Symantec Advanced Manager and Symantec Event Manager provide secure, centralized,

Web-based management of hundreds or thousands of security gateway deployments.

BLACKICE SERVER PROTECTION

B-44. BlackICE Server Protection (personal firewall) intrusion detection capabilities automatically detect

and block malicious activities by monitoring all inbound and outbound traffic passing through the server.

Users are instantly alerted of an attack and can easily identify the source and the method being used. Once

an attempt is detected, BlackICE Server Protection automatically blocks traffic from that source so that the

intruder is no longer a threat. BlackICE Server Protection also provides exhaustive reporting for common

attacks on servers.

INFORMATION DISSEMINATION MANAGEMENT/CONTENT

STAGING

INFORMATION DISSEMINATION MANAGEMENT-TACTICAL

B-45. IDM-T (SharePoint Portal, SQL Server 2000, iOra) is a system that provides a set of Web-based

management tools for locating, transporting, and storing information products that meet the commander’s

critical information requirements. IDM-T is a combination of commercial off-the-shelf and government off-

the-shelf products that include Microsoft Sharepoint Portal Server 2003, Server 2003, SQL Server 2000,

SQL Server SP 3A, and iOra Software (not currently resident in all units, specifically the 3ID). IDM-T

government off-the-shelf products include Web parts that include the following: request for information

suite, briefing builder for battlefield update briefings, configurable clocks (time zone and count down

banners), and commander’s status board features.

B-46. Microsoft SharePoint Portal Server 2003 provides an enterprise business solution that integrates

information from various systems into one solution, through single sign-on and enterprise application

integration capabilities, with flexible deployment options and management tools. The portal facilitates end-

to-end collaboration by enabling aggregation, organization, and search capabilities for people, teams, and

information. Users can find relevant information quickly through customization and personalization of

portal content and layout, as well as by audience targeting. Organizations can target information, programs

and updates to audiences based on their organizational role, team membership, interest, security group, or

any other defined membership criteria.

B-47. The SQL Server 2003 provides the enterprise data management platform to adapt in a fast-changing

environment. It is benchmarked for scalability, speed, and performance. The SQL Server 2003 is a fully

enterprise-class database product that provides core support for eXtensible Markup Language and Internet

queries.

B-48. iOra for Microsoft SharePoint

(not currently resident in all units, specifically the

3ID) is a

collaboration tool that enables mobile use of SharePoint Portal capabilities by enabling users to browse and

access the same Microsoft SharePoint content and functionality both online and offline. This software

avoids dead links and ensures that integrated document management is constantly active.

B-49. Microsoft Exchange Server 2003 is messaging software that runs on servers and enables users to

exchange individual and organizational e-mail and other forms of interactive communication through

computer networks. Designed to interoperate with a software client application such as Microsoft Outlook

and the Defense Message System User Agent (client software), Exchange Server also interoperates with

Outlook Express and other e-mail client applications.

B-12

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

NETWORK OPERATIONS SYSTEMS AND TOOLS

B-50. The Army information system hosts the common service capabilities for the ABCS resident on the

LAN. It primarily serves as a publish-and-subscribe server, coordinating the information produced by

individual ABCS platforms. Through the use of a global positioning system connection, the Army

information system also provides timing to the different ABCS platforms resident on the LAN.

B-51. The SUN ONE server is used in conjunction with integrated battle command picture/publish-and-

subscribe server services. It controls Hypertext Transfer Protocol

(HTTP) and Hypertext Transfer

Protocol/Secure (HTTPS) access to the publish-and-subscribe server portal.

B-52. The TOMCAT Server is a credentialing mechanism used in the Army information system server. It

grants access to the global command and control system administration log tool (GSALT) once certificates

have been verified. It also verifies all incoming connections for a security DOD root certificate.

B-53. The GSALT Server is a global command and control system administration log tool. It provides

authentication and credential services through the GSALT administrative application. It is used in

conjunction with TOMCAT to access command and control registry data. Services must be running to

access the GSALT administrative console. The GSALT administrative console is used to give publishing

privileges to open topics for the individual warfighting functions that will be connected to the Army

information system.

B-54. The Integrated Battle Command Picture/publish-and-subscribe server provides the publish-and-

subscribe server portal. It is used to create topics, and controls data flowing in and out of the Army

information system server.

B-55. The command and control registry is administered by the command and control registry planner. It

provides the common means of managing the address information that is vital to military messaging. It also

allows a user to determine the unit reference number, IP address, host name, and other address data of a

particular platform or unit. The command and control registry synchronizes this data across ABCSs so that

all systems have the same addressing information. These capabilities support the configuration of the

ABCSs.

B-56. State management provides a means by which elements of the ABCS network have the most current

information. The data consists mainly of warning orders, OPORDs, FRAGOs, and unit task reorganizations.

19 November 2008

FM 6-02.71

B-13

FOR OFFICIAL USE ONLY

Appendix C

Tactical Network Operations Scenarios

This appendix provides examples of the process flows for various NETOPS activities

that may occur in the tactical environment. It will focus on familiar examples from

known problem areas within the framework of Chapter 5.

OVERVIEW

C-1. Below are some general guidelines that are followed during the development of the scenarios

referenced throughout this appendix:

Follow the operational models previously established in Chapter 5.

Remain consistent with the AENIA, joint and Army NETOPS CONOPS, etc.

Establish best practices consistent with the proper tradeoff between commercial best practices

versus tactically unique requirements. Solid rationale is presented for deviations from

commercial best practices.

C-2. The intent is that signal Soldiers in the field will be able to use these scenarios to understand the

operational context and employment of the NETOPS activity under question.

C-3. These processes are depicted in a business process diagram using the business process modeling

notation (BPMN) version 1.0 specification. The BPMN 1.0 specification (BPMN, May 2004) provides a

detailed and useful definition: The BPMN specification provides a graphical notation for expressing

business processes in a business process diagram. The objective of BPMN is to support business process

management by both technical users and business users. This objective is achieved by providing a notation

that is intuitive to business users yet able to represent complex process semantics. The BPMN specification

also provides a mapping between the graphics of the notation and the underlying constructs of execution

languages, particularly business process execution language for Web services.

C-4. Several symbols are used in the business process diagrams that should be described for clarity. Figure

C-1 and C-2 serve as a legend for the business process diagrams contained within this section.

19 November 2008

FM 6-02.71

C-1

FOR OFFICIAL USE ONLY

Appendix C

Events with “Message” Trigger

A message arrives from a

participant and triggers the

start of the Process.

A message arrives from a

participant and triggers the

continuation of the

Process.

This type of End indicates that a

message is sent to a participant at

the conclusion of the Process .

Timer Events

A specific time-date or a specific

Start Timer

Event

cycle (e.g., every Monday at 9am)

can be set that will trigger the start

of the Process or Activity.

Intermediate

Timer

Event

A Message Flow is used to show the flow of

messages between two participants that are

prepared to send and receive them . In

BPMN, two separate Pools in the Diagram

will represent the two participants (e.g.,

business entities or business roles ).

A Sequence Flow is used to show the order

that activities will be performed in a Process .

Text Annotations are a mechanism for

Enter Text Here

a modeler to provide additional

Enter Text Here

information for the reader of a BPMN

Diagram .

Figure C-1. BPMN flow and connection elements

C-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

A Pool represents a Participant in a

Process. It is also acts as a ―swimlane‖ and

a graphical container for partitioning a set of

activities from other Pools, usually in the

context of B2B situations.

A Lane is a sub-partition within a Pool and

will extend the entire length of the Pool ,

either vertically or horizontally . Lanes are

used to organize and categorize activities .

An activity is a generic term for work that an

Activity

organization performs .

Decisions are Gateways within a

Gateway

business process where the flow of

control can take one or more

alternative paths .

Figure C-2. BPMN core elements

NON-GLOBAL CONFIGURATION MANAGEMENT AND CHANGE

MANAGEMENT SCENARIO

C-5. The following scenario explains the activities involved in implementing a configuration change on a

network device within the Army’s enterprise. This configuration change is considered non-global, as it

requires a change to be made only at a single battalion level within the Army enterprise. When a

configuration change is required that affects devices across the Army enterprise, it is then considered a

global configuration change. A scenario illustrating a global configuration change is provided in the next

section.

C-6. Although the narrative for this scenario focuses on implementing a change to the configuration on a

port of a firewall, it details the activities associated with the change management process in general;

therefore, it is applicable to implementing any type of non-global change within the theater enterprise.

C-7. The process flow depicted in Figure C-3 describes the actions taken by various organizations within

the tactical echelons, residing in an Army theater, as they react to a new application being added to support

a battalion command post’s mission.

C-8. It is important to note that NETOPS activities rely on one another in order to complete a process. To

emphasize this fact, portions of related NETOPS activities are included in this scenario’s diagram in

addition to change management activities. The scenario in Figure C-3 begins with the incident and problem

management activity. It should be noted that the incident and problem management activity has been

abbreviated in this scenario for the purpose of simplicity. The change management activity can be found in

the incident and problem management activity which begins in Step 10 of the scenario. The change

management activity continues through Step 15 and provides the mechanism in which an orderly and

coordinated change is implemented to the firewall’s port configuration. CM is also an integral activity of

this scenario. It is initiated as a result of the change management activity and occurs in Steps 14 through 16

19 November 2008

FM 6-02.71

C-3

FOR OFFICIAL USE ONLY

Appendix C

(some of the steps in the scenario apply to more than one activity). CM ensures that the new configuration

of the firewall is documented and made available to all interested organizations.

ASSUMPTIONS

C-9. This scenario assumes that there is a pre-established firewall configuration change policy in effect at

the theater. It also assumes that the standard configuration policy for the theater’s firewalls specifies deny

all and permit by exception and that the port to be changed on the battalion’s firewall is associated with a

theater-approved application.

C-10. This scenario also assumes that the division has the final authority to approve the configuration

change in question given that the firewall is an echelon-above-brigade managed system. The ARFOR

NOSC is not required to approve the change unless otherwise directed, but notification of the change is

required.

C-11. This scenario further assumes that a configuration database system is in operation within the theater,

which facilitates the viewing of all configuration changes for all organizations.

SCENARIO NARRATIVE

C-12. This scenario begins with a new application being added to support a battalion command post

mission. Since the application was not resident in the battalion command post at the onset of operations,

deny all and permit by exception protocol results in the application’s communication port being blocked at

the local firewall. The designations G-6 and S-6 refer to both the individual and staff. The following are

step-by-step instructions for the scenario—

Step 1: The battalion S-6 receives a message from a user on the battalion network stating that a

newly installed application is not functioning properly.

Step 2: The battalion S-6 investigates the problem, but cannot determine the cause. If the cause

of the problem can be determined and corrective action is authorized, then the process

proceeds to Step 18.

Step 3: The battalion S-6 notifies the BCT S-6 of the problem.

Step 4: The BCT S-6 directs the brigade signal company to investigate the problem.

Step 5: The BCT signal company collaborates with the battalion S-6 to troubleshoot the

problem, but cannot determine the cause.

Step 6: The BCT S-6 notifies the G-6 of the problem.

Step 7: The G-6 directs the Warfighter Integration and Support Cell (WISC) to investigate the

problem.

Step 8: The WISC collaborates with the BCT signal company and the battalion S-6 to

investigate and identify the cause of the problem (a blocked port on the battalion

command post’s firewall). Since the problem was identified by the WISC, it should be

noted that the ARFOR and TNOSC do not get involved in the troubleshooting process.

Step 9: The WISC notifies the G-6, the BCT S-6, and the battalion S-6 of the cause of the

problem.

Step 10: The battalion S-6 submits a firewall port configuration request for change to the BCT

S-6 to have the blocked port opened.

Step 11: The BCT S-6 receives, validates, and forwards the firewall port configuration request

for change to the G-6.

Step 12: The division G-6 receives and approves the firewall port configuration request for

change.

Step 13: The division G-6 directs the WISC to schedule the firewall port configuration change.

Step 14: The WISC consults the G-6, BCT S-6, and battalion S-6 for an available execution

window, schedules the firewall port configuration change, and notifies the G-6, the

BCT S-6, and the battalion S-6 of the schedule.

C-4

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

Step 15: At the scheduled time, the WISC executes the firewall port configuration change.

Step 16: The WISC updates the configuration database and notifies the ARFOR NOSC, the

TNOSC, the G-6, the BCT S-6, and the battalion S-6 that the change has been

executed.

Step 17: The battalion S-6 verifies that the application is now functional (if it is not functional,

then the process begins again from Step 2).

Step 18: The process ends when the battalion S-6 verifies that the application is functional.

Problem determined to be

caused by a blocked port on

Develop & Coordinate

the BN CP’s firewall

Firewall Port

Execute Firewall Port

Update Configuration

Notify G6,

Configuration Change

Change

Database

Investigate Problem &

Brigade S6, and

Schedule

Identify Cause

BN S6

Awaiting Scheduled Time

of Change

Collaborative

Troubleshooting

Direct WISC to

Receive & Approve

Schedule Firewall

Investigate Problem

RFC

Port Configuration

Change

Investigate

Cause of Problem

Problem & Identify

Determined &

Cause

Corrective Action

Authorized?

Yes

Collaborative

Troubleshooting

Direct Brigade

Notify G6

Signal Company to

Receive, Approve, &

Investigate Problem

Forward RFC

Investigate

Cause of Problem

Notify Higher-

Problem & Identify

Determined &

level

Cause

Corrective Action

Organizations

Submit RFC to

Authorized?

Open Firewall Port

Yes

Problem

Verify problem has been

The BN S6 receives

Corrected?

corrected

notification that a new

Corrective Action Provided and/or Implemented

application on the

network is not functioning

Incident/Problem Management Activity

Configuration Management Activity

Change Management Activity

Combined Change Management and

Configuration Management Activities

Figure C-3. Non-global configuration change scenario

19 November 2008

FM 6-02.71

C-5

FOR OFFICIAL USE ONLY

Appendix C

GLOBAL CONFIGURATION CHANGE SCENARIO

C-13. The following scenario illustrates the activities involved in implementing a change on a network

device within the Army’s enterprise. This change is considered global, as it requires a change to be made to

all devices within the Army enterprise. When a change is required that only affects devices within a small

portion of the Army enterprise it is then considered a non-global change. A scenario illustrating a non-

global change is also provided above.

C-14. Although the narrative for this scenario focuses on implementing a change to the ACL configuration

of the theater’s routers, it details the activities associated with the change management process in general;

therefore, it is applicable to implementing any type of global change within the theater enterprise.

C-15. The process flow depicted in Figure C-4 illustrates the actions taken by various organizations, within

the theater and Army level echelons, as they react to a directive from the A2TOC to change the ACL

configurations on all Army routers within the theater.

C-16. As stated earlier, NETOPS activities are interdependent. This scenario involves the CM activity in

addition to change management. The change management activity occurs in Steps 1 through 7.1. This

activity is initiated as the result of the A2TOC directing a global change to all Army routers’ configurations.

It also provides the mechanism in which an orderly and coordinated change is implemented. CM is also an

integral activity in this scenario. It is initiated as a result of the change management activity and occurs in

Step 7, 7.1, and 8 in the scenario (some of the steps in the scenario apply to more than one activity). CM

ensures that the new configuration of the Army routers is documented and made available to all interested

organizations.

ASSUMPTIONS

C-17. This scenario assumes that there is a pre-established router ACL configuration change policy in effect

in the theater. This scenario further assumes that because the change originated from the A2TOC the

ARFOR NOSC is required to approve such a change. It is also assumed that the ARFOR NOSC will

approve the change.

C-18. In addition, this scenario assumes that a configuration database system is in operation within the

theater, which then facilitates the viewing of all configuration changes for all organizations.

SCENARIO NARRATIVE

C-19. This scenario in Figure C-4 is triggered by a notification to the TNOSC from the A2TOC that an

Army-wide change to router ACL configurations must be implemented throughout the theater. The

following is a step-by-step explanation for the scenario—

Step 1:

The TNOSC receives notification from the A2TOC that the ACL configurations on

all Army routers within the theater must be changed.

Step 2:

The TNOSC notifies the ARFOR NOSC of the ACL change criteria and requests

approval to initiate the implementation of the change. If the ARFOR NOSC approves

the change, then the process continues with Step 3. If the ARFOR NOSC does not

approve the change, then the process continues with Step 3.1.

Step 3:

Upon approval, the TNOSC disseminates the ACL change criteria to the G-6 at the

division.

Step 3.1: Upon non-approval, the TNOSC notifies the A2TOC that the change is not approved

by the ARFOR NOSC and requests further direction. At this point, the process ends,

and the A2TOC and the ARFOR NOSC address the issue of the ACL configuration

change approval.

Step 4:

Upon notification from the TNOSC of the ACL configuration change, the G-6 directs

the WISC to schedule the ACL configuration change.

C-6

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

Step 5:

The WISC develops and coordinates a schedule for the ACL configuration change. The

schedule is provided to ARFOR NOSC, the A2TOC, the TNOSC, the G-6, the BCT S-6,

and the battalion S-6. Upon notification from the TNOSC of the ACL configuration

change, the ARFOR NOSC develops and coordinates a schedule for the ACL

configuration change. The schedule is provided to all corps and above Army networks

and any expeditionary BCTs within the ARFOR AOR.

Step 6:

The WISC, ICW each vested organization, implements the ACL configuration change for

the division AOR. At the prescribed time, the ARFOR NOSC, ICW each vested

organization, implements the ACL configuration change for all echelon above corps

Army networks and any expeditionary BCTs within the ARFOR AOR.

Step 7:

The WISC notifies each vested organization that the change has been executed. It should

be noted that if the change has any adverse effects, then the incident and problem

management process described next will be initiated.

Step 7.1: The process ends with the ARFOR NOSC notifying each vested organization that the

change has been executed. It should be noted that if the change has any adverse effects,

then the incident and problem management process described in the next section will be

initiated.

Step 8:

Upon notification that directed changes have been made, the A2TOC updates the

configuration database.

19 November 2008

FM 6-02.71

C-7

FOR OFFICIAL USE ONLY

Appendix C

Army-wide change to all

Update Configuration

router ACLs

Database

Notification that

A2TOC notifies theaters of an

Notification that change

change has been executed

Army-wide configuration policy change

was not approved

in ARFOR

5.1

6.1

7.1

Develop & coordinate

Execute router ACL

Notify A2TOC that the

router ACL configuration

configuration change

change has been

change schedule for

in ARFOR

executed

ARFOR

Awaiting Scheduled Time

of Change

Change

approved?

Yes

Notification to change

all tactical router ACLs

3.1

Notify A2TOC

Request

Disseminate

for further

approval to

direction

implement

policy change

criteria

Notification to change

change

all Army router ACLs

Notification that

Notification of change

change has been executed

schedule for tactical AOR

in tactical AOR

Develop & coordinate

router ACL configuration

Execute router ACL

Notify organizatins that

change schedule for

configuration change

the change has been

tactical AOR

in tactical AOR

executed

Awaiting Scheduled Time

of Change

Direct WISC to

schedule router ACL

configuration change

Notification that

Notification to change

Notification & coordination

change has been executed

all tactical router ACLs

of change schedule

in tactical AOR

Combined Change Management and

Change Management Activity

Configuration Management Activities

Configuration Management Activity

Figure C-4. Global configuration change scenario

INCIDENT AND PROBLEM MANAGEMENT SCENARIO

C-20. The process flow depicted in Figure C-5 describes the actions taken by various organizations, within

the echelons residing in an Army theater, as they react to a capability-related incident and problem and the

ensuing trouble ticket.

C-21. The following scenario works through the activities involved in managing a capability-related

incident or problem. This scenario illustrates a situation where there is a problem at the battalion level and

the problem is escalated all the way to the TNOSC, if necessary, to resolve the issue. It is the responsibility

C-8

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

of the ARFOR NOSC to involve the TNOSC if the ARFOR NOSC is unable to resolve the problem on its

own.

C-22. Although this scenario focuses on the processing of incidents or problems related to capabilities, it is

also applicable to processing any type of incident or problem within the enterprise.

C-23. As stated earlier, NETOPS activities are interdependent. This scenario involves both the change

management and CM activities in addition to incident and problem management. The incident and problem

management activity occurs when the battalion S-6 opens a trouble ticket concerning a capability that has

been reported by a battalion subscriber. When the battalion S-6, signal company, WISC, ARFOR NOSC, or

TIC determines the cause of the problem and performs corrective actions (Steps 4.1, 7.1, 10.1, 12.1, and

14.1, respectively), these steps involve the incident and problem management activity as well as the change

management and CM activities. In performing corrective actions, some type of change will eventually be

made to a system or the network. At this time, the change management activity is initiated. This activity

provides the mechanism in which an orderly and coordinated change is implemented. The change

management activity will normally result in some type of configuration change. The resulting configuration

change will initiate the CM activity in which the altered configuration will be documented. This will ensure

that the new configuration, resulting from correcting an incident or problem, is documented and made

available to all organizations.

ASSUMPTIONS

C-24. This scenario assumes that a customer relationship management system is in operation within the

theater, which facilitates the notification of capability-related incidents and problems to the responsible

organizations. It is also assumed that the customer relationship management system facilitates the

processing of trouble tickets related to incidents and problems. Consequently, each organization within the

theater is capable of viewing each trouble ticket through its lifecycle.

C-25. This scenario also assumes that the theater maintains a knowledge base that is available to each

organization in the theater that contains historical data related to past problems, their causes, and their

resolutions.

Scenario Narrative

C-26. This scenario is depicted in Figure C-5. The process is triggered by a notification to the battalion S-6

from a local subscriber that a capability is not functioning. The following is a step-by-step explanation for

the scenario—

Step 1:

A battalion subscriber notifies the battalion S-6 that a capability is not functioning.

Step 2:

The battalion S-6 opens a trouble ticket for the unknown problem. Note that through the

customer relationship management system, all organizations are capable of viewing the

trouble ticket. The BCT S-6 tracks the trouble ticket and alerts the BCT signal company

that their services may be required to resolve the problem. Similarly, the G-6 tracks the

trouble ticket and alerts the WISC that their services may be required to resolve the

problem. The TNOSC and ARFOR NOSC also track the trouble ticket.

Step 3:

The battalion S-6 queries the theater’s knowledge base to determine if the problem has

been encountered previously and, if so, what corrective action was taken. If the problem

is not found in the theater’s knowledge base, then the process continues with Step 4. If the

problem is found in the theater’s knowledge base, then it is re-categorized as an incident

and the process continues with Step 4.1.

Step 4:

The battalion S-6 collaborates with the battalion subscriber and investigates the problem.

If the cause of the problem is determined and the corrective action is authorized, then the

process continues to Step 4.1. If the problem cannot be determined or the corrective

action is not authorized, then the process continues to Step 5.

Step 4.1: Throughout the change management activity, the battalion S-6 instigates corrective

actions for the problem and the process continues to Step 4.2.

19 November 2008

FM 6-02.71

C-9

FOR OFFICIAL USE ONLY

Appendix C

Step 4.2: Upon completion of corrective actions, the battalion S-6 updates and closes the trouble

ticket and documents any configuration changes. The process then continues to Step 15.

Step 5:

The battalion S-6 updates the trouble ticket and escalates it to the BCT, and the process

continues to Step 6. It is important to note that the BCT S-6 and BCT signal company are

capable of viewing the updated trouble ticket.

Step 6:

The BCT S-6 directs the BCT signal company to investigate the problem.

Step 7:

The BCT signal company collaborate with the battalion S-6 and the battalion subscriber

to investigate the problem. If the cause of the problem is determined and the corrective

action is authorized, then the process continues to Step 7.1. If the problem cannot be

determined or the corrective action is not authorized, then the process continues to Step 8.

Step 7.1: Through the change management activity, the BCT signal company instigate corrective

actions for the problem and the process continues to Step 7.2.

Step 7.2: Upon completion of corrective actions, the BCT signal company update and close the

trouble ticket and record any configuration changes. The process then continues to

Step 15.

Step 8:

The BCT signal company updates the trouble ticket and the BCT S-6 escalates it to the

division. The process then continues to Step 9. It is important to note that both the G-6

and the WISC are capable of viewing the updated trouble ticket.

Step 9:

The G-6 directs the WISC to investigate the problem.

Step 10:

The WISC collaborates with the BCT S-6, the battalion S-6, and the battalion subscriber

to investigate the problem. If the cause of the problem is determined, then the process

continues to Step 10.1. If the problem cannot be determined the process continues to

Step 11.

Step 10.1: Throughout the change management activity, the WISC instigates corrective actions for

the problem and the process continues to Step 10.2.

Step 10.2: Upon completion of corrective actions, the WISC updates and closes the trouble ticket and

documents any configuration changes. The process then continues to Step 15.

Step 11: The WISC updates the trouble ticket and escalates it to the ARFOR NOSC and the

process continues to Step 12.

Step 12: The ARFOR NOSC collaborates with the WISC, the BCT S-6, battalion S-6, and

battalion subscriber to investigate the problem. If the cause of the problem is determined,

then the process continues to Step 12.1. If the problem cannot be determined, then the

process continues to Step 13.

Step 12.1: Through the change management activity, the ARFOR NOSC instigates corrective actions

for the problem and the process continues to Step 12.2.

Step 12.2: Upon completion of corrective actions, the ARFOR NOSC updates and closes the trouble

ticket and documents any configuration changes. The process then continues to Step 15.

Step 13: The ARFOR NOSC updates the trouble ticket and escalates it to the TNOSC and the

process continues to Step 14.

Step 14: The TNOSC collaborates with the ARFOR NOSC, the WISC, the BCT S-6, the battalion

S-6, and the battalion subscriber to investigate the problem. If the cause of the problem is

determined, then the process continues to Step 14.1. If the cause of the problem is not

identified, the TNOSC will consult subject matter experts, vendors, or other sources until

the problem is resolved. Then the process will continue with Step 14.1.

Step 14.1: Through the change management activity, the TNOSC performs corrective actions for the

problem and the process continues to Step 14.2.

Step 14.2: Upon completion of corrective actions, the TNOSC updates and closes the trouble ticket

and documents any configuration changes. The process then continues to Step 15.

Step 15: Upon notification of the closed trouble ticket, the TNOSC updates the theater’s

knowledge base with the corrective actions taken to resolve the problem. It is important to

C-10

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Appendix C

Provides oversight of

problem resolution

Provides oversight of

problem resolution

12.1

12.2

Investigate Problem

Cause

Yes

Perform

Update & Close

& Identify Cause

Determined ?

Corrective Action

Trouble Ticket

Accomplished via the Change

Update Trouble

Management activity. See section 6.2

Ticket & Escalate

for examlple

Collaborative

Troubleshooting

Collaborative

Troubleshooting

Provides oversight of

problem resolution

14.1

14.2

Update Theater

Investigate Problem

Perform

Update & Close

Knowledge Base

& Identify Cause

Corrective Action

Trouble Ticket

Closed Trouble Ticket

Closed trouble

ticket viewable by

all organizations

Update Trouble

Ticket & Escalate

10.1

10.2

Investigate

Yes

Problem & Identify

Cause

Perform

Update & Close

Cause

Determined ?

Corrective Action

Trouble Ticket

Provides oversight of

problem resolution

Direct WISC to

and alerts WISC as

Investigate Problem

required

Collaborative

Troubleshooting

7.1

7.2

Update Trouble

Perform

Update & Close

Ticket & Escalate

Corrective Action

Trouble Ticket

Yes

Updated trouble

Closed trouble

ticket viewable by

Investigate

ticket viewable by

all organizations

Cause Determined

Problem & Identify

all organizations

& Corrective Action

Authorized?

Cause

Provides oversight of

Direct Brigade

Updated trouble

Signal Company to

ticket viewable by

problem resolution and

Investigate Problem

alerts NSC as required

all organizations

Collaborative

Troublshooting

Problem now categorized

Query Theater’s

as an Incident

Update Trouble

Knowledge

Base

Ticket & Escalate

Yes

4.1

4.2

Problem

Identified in

Investigate

Cause Determined

Yes

Perform

Update & Close

Knowledge

Problem & Identify

& Corrective Action

Corrective Action

Trouble Ticket

Open Trouble

Base?

Cause

Collaborative

Authorized?

Ticket via web

Troubleshooting

Trouble Ticket

Subscriber notifies

BN S6 of an issue

with a capability

Combined Incident/Problem Manatement, Change

Incident/Problem Management Activity

Management, and Configuration Management Activities

Figure C-5. Incident and problem management scenario

C-12

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

POLICY MANAGEMENT SCENARIO

C-27. The following scenario works through the activities involved in implementing and managing a

temporary exception to policy. Although the narrative for this scenario focuses on the temporary exception

to border routing policy, it details the activities associated with policy management in general. Therefore, it

is applicable to managing any type of Army tactical policy.

C-28. The process flow depicted in Figure C-6 describes the actions taken by various organizations, within

the tactical echelons residing in an Army theater, as they identify and process a temporary exception to BCT

border router policy.

ASSUMPTIONS

C-29. This scenario assumes that there is a pre-established BCT border router configuration policy in effect.

It is further assumed that the standard configuration policy for the BCT border routers specifies that no

redistribution of foreign routes is allowed into the Border Gateway Protocol process.

Scenario Narrative

C-30. This scenario is depicted in Figure C-6. The scenario begins when the BCT is tasked to support a

non-organic group of networks. The following is a step-by-step explanation for the scenario—

Step 1:

During the course of a mission, the BCT is tasked to support a non-organic group of

networks. To support this task, the BCT identifies a need for a temporary exception to

policy regarding border router redistribution. Throughout the change management

activity, the BCT S-6 sends a request for change requesting a temporary exception to

policy. The request is sent to its commanding headquarters, which is currently a

division, for review.

Step 2:

The division G-6 analyzes the request, and if the division G-6 agrees that the request is

valid, then the process continues with Step 3. If the division G-6 does not agree with

the request, then the process continues with Step 3.1 and the scenario ends.

Step 3:

The division G-6 determines if the temporary exception to policy request could have an

adverse impact on the availability or security of networks external to the division and

BCT. If possible, the process continues with the Step 4.1. If not, the scenario continues

with Step 4.

Step 3.1:

The division G-6 notifies the BCT S-6 that the temporary exception to policy has been

rejected based upon possible mission ramifications. The division may suggest an

alternate solution or instruct the BCT to operate as effectively as possible within the

boundaries of Army policy.

Step 4:

The division G-6 notifies the BCT that the temporary exception to policy has been

approved. The division also notifies the ARFOR of the temporary exception to policy

for informational purposes. ARFOR notifies its parent joint command and numbered

Army TIC of the temporary exception to policy. The numbered Army TIC notifies

other numbered Army components (e.g., SC[T]) and the A2TOC of the temporary

exception to policy. The A2TOC then notifies the CIO G-6 and the US Army Signal

Center of the temporary exception to policy. The activity then continues with Step 5.

Step 4.1:

The division G-6 sends the temporary exception to policy request to its commanding

headquarters, which is the ARFOR.

Step 4.2:

The ARFOR analyzes the temporary exception to policy request. If the ARFOR

determines that the temporary exception to policy is valid, then the process continues

with Step 4.3. If the ARFOR determines that the temporary exception to policy is not

valid, then the process continues with Step 4.3.1.

Step 4.3:

The ARFOR determines if this temporary exception to policy could have an adverse

impact on the availability or security of networks external to the ARFOR. If possible,

the process continues with the next step.

19 November 2008

FM 6-02.71

C-13

FOR OFFICIAL USE ONLY

Appendix C

Step 4.3.1: The ARFOR notifies the division G-6 that the temporary exception to policy has been

rejected based upon possible mission ramifications. ARFOR may suggest an alternate

solution or instruct the BCT to operate as effectively as possible within the boundaries

of Army policy. The scenario then returns to Step 3.1.

Step 4.4:

The ARFOR notifies the division G-6 that the temporary exception to policy has been

approved. The process returns to Step 4.

Step 4.4.1: Processing for the temporary exception to policy request is forwarded to the ARFOR’s

joint headquarters. Activities are then dictated by joint policy and the scenario ends.

Step 5:

Throughout the change management and CM activities, the BCT implements the

temporary exception to policy. The scenario then continues with Step 6.

Step 6:

Upon redeployment, the BCT, through the change management and CM activities,

revokes the temporary exception to policy and reconfigures border routers to once

again comply with permanent Army policy. During redeployment after action review,

the BCT may identify a need to alter permanent Army policy regarding BCT border

router configurations in order to capture lessons learned. The BCT submits this policy

change proposal via the chain of command.

C-14

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

4.4.1

4.3

Temporary

Forward

Exception to

Yes

Temporary

Yes

Policy May Impact

Exception to

4.3.1

External

Policy Proposal to

4.2

Networks?

Joint Command

Notify Div/CORPS

4.4

Is Temporary Exception

Temporary

to Policy Valid/

Notify Div/CORPS

Exception to Policy

of Temporary

Disapproval

Exception to

Policy Approval

4.1

Temporary

Forward RFC for

Exception to

Yes

Temporary

Yes

Policy May Impact

Exception to

External

3.1

Policy to ARFOR

Networks?

Notify BCT of

Is Temporary

Disapproval of

Notify all

Exception to Policy

Temporary

organizations of

Valid?

Exception to

Temporary

Policy

Exception to

Policy Approval

Implement Temporary

Revoke Temporary Exception to

Submit RFC requesting

Exception to Policy and

Policy and update Configuration

Division Approval for

update Configuration

Management Database

Temporary Exception to

Management Database

Policy

Awaiting End of Mission

Combined Change Management and

Change Management Activity

Configuration Management Activities

Figure C-6. Policy management scenario

19 November 2008

FM 6-02.71

C-15

FOR OFFICIAL USE ONLY

Appendix C

NETWORK OPERATIONS SHARED SITUATIONAL AWARENESS

SCENARIO

C-31. The following scenario works through the activities involved in developing and requesting theater

NETOPS shared SA views.

C-32. The process flow depicted in Figure C-7 describes the actions taken by various organizations, within

the tactical echelons residing in an Army theater, as they prepare systems to support the development of

tailored theater NETOPS shared SA views by the TNOSC. The scenario also provides information

concerning the process that is necessary to request tailored views, for various uses, at their echelon.

ASSUMPTIONS

C-33. This scenario assumes that the TNOSC plays a role in the infrastructure monitoring processes and

NETOPS shared SA development for Army theaters down to the BCT level.

SCENARIO NARRATIVE

C-34. This scenario is depicted in Figure C-7. The following is a step-by-step explanation for the

scenario—

Step 1:

Army doctrine, policy, and guidance direct the development of a NETOPS shared SA for

all missions given in any theater.

Step 2:

TIC personnel will be responsible for ensuring the relevant tactical systems within the

numbered Army and TNOSC AOR are equipped and configured to report OPORD 05-01

required NETOPS shared SA data to the TNOSC.

Step 3:

Through the infrastructure monitoring processes, the TNOSC will begin to receive theater

OPORD 05-01 NETOPS shared SA data.

Step 4:

The TNOSC will store and normalize the theater NETOPS shared SA data.

Step 5:

The TNOSC will develop an aggregated theater NETOPS shared SA view that is

automatically forwarded to the A2TOC. The TNOSC will develop specific NETOPS

shared SA views based on requests from theater consumer organizations.

Step 6:

The A2TOC will automatically receive an aggregated theater NETOPS shared SA view

from the TNOSC.

Step 7:

The A2TOC will take all the aggregated theater NETOPS shared SA views from all Army

theaters and produce an Army NETOPS shared SA view.

Step 8:

Either prior to or upon entry to an Army theater, the BCT S-6 will direct the BCT signal

company to equip and configure all relevant systems in the BCT AOR in order to report

NETOPS shared SA data.

Step 8.1:

The signal company personnel will be responsible for ensuring the relevant systems

within the BCT AOR are equipped and configured to report OPORD 05-01 required

NETOPS shared SA data to the TNOSC.

Step 9:

Either prior to or upon entry to an Army theater, the division G-6 will direct the WISC to

equip and configure all relevant systems in the division AOR in order to report NETOPS

shared SA data.

Step 9.1:

WISC personnel will be responsible for ensuring the relevant systems within the division

AOR are equipped and configured to report OPORD 05-01 required NETOPS shared SA

data to the TNOSC.

Step 10:

Upon its instantiation as a joint operational area command, the ARFOR NOSC will be

responsible for ensuring the relevant systems within the ARFOR AOR are equipped and

configured to report OPORD 05-01 required NETOPS shared SA data to the TNOSC.

Step 11:

At any time the BCT commander or BCT staff may need specific NETOPS shared SA

views to ascertain the health of the NETOPS capabilities.

C-16

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Tactical Network Operations Scenarios

Step 11.1: The BCT S-6 will request appropriate NETOPS shared SA views from the TNOSC.

Step 11.2: The BCT S-6 will receive requested NETOPS shared SA views from the TNSOC.

Step 12: At any time the division commander or division staff may need specific NETOPS shared

SA views to ascertain the health of the NETOPS capabilities.

Step 12.1: The division G-6 will request appropriate NETOPS shared SA views from the TNOSC.

Step 12.2: The division G-6 will receive requested NETOPS shared SA views from the TNOSC.

Step 13: At any time the CCDR, JTFs, JFLCCs, JNCCs, theater NETOPS centers, and TNCCs

may require specific NETOPS shared SA views to quickly assess and react to capability

degradations that impact, or have the potential to impact, its warfighting capability.

Step 13.1: The ARFOR NOSC will request the appropriate NETOPS shared SA views from the

TNOSC.

Step 13.2: The ARFOR NOSC will receive requested NETOPS shared SA views from the TNOSC.

19 November 2008

FM 6-02.71

C-17

FOR OFFICIAL USE ONLY

Appendix C

Produce Army NETOPS

shared SA views

Receive Theater NETOPS shared SA views

12.1

12.2

Request NETOPS

shared SA views

Receive NETOPS shared SA views

Equip and configure

Produce Theater

relevant systems

Store and normalize SA

NETOPS shared

within AOR to report

data

SA data

SA views

Doctrine and Policy direct

Receive ASR 25-6 data

TNOSC to produce

as a part of infrastructure

TheaterNETOPS shared SA views

monitoring processes

9.1

Equip and configure

relevant systems

within AOR to report

SA data

11.2

11.1

Request

Receive NETOPS shared SA views

Directs WISC

NETOPS shared

to equip and configure

relevant systems within AOR

SA views

to report SA data

8.1

Equip and configure

relevant systems

within AOR to report

SA data

10.2

Receive NETOPS shared SA views

10.1

Directs Brigade Signal Company

Request NETOPS

to equip and configure

shared SA views

relevant systems within AOR

to report SA data

Figure C-7. NETOPS shared SA scenario

C-18

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Appendix D

Network Management and Operations: Division

This appendix provides division commanders and staff members an understanding of

systems and personnel that comprise the communications network at division and

below. It also provides brief overviews of the related mission responsibilities of the

division G-6, division signal company and the brigade and battalion level

communications capabilities and responsibilities.

OVERVIEW

D-1. As the primary tactical and operational war fighting headquarters the division requires a robust

command and control information network architecture supported by NETOPS personnel at division and

below. The division is supported by organic G-6 section NETOPS (network management, IDM and IA)

personnel and by the network transport personnel and assets within the division signal company. These

personnel and assets install, operate, maintain, manage and defend the federations of networks. The

federation of networks collectively enables joint and expeditionary battle command. The network enables

leaders to command and control maneuver formations, sustain the force, and achieve broad political military

objectives across the full spectrum of operations. It is an integrated entity and pervasive throughout the

operational environment and touches every entity, to include the individual Soldier. The network as a

critical weapon in the fight must be robust, redundant, flexible and adaptive to the commander.

DIVISION G-6

D-2. The division G-6 is the senior signal officer who exercises staff oversight of the division information

network and has the level of experience to anticipate the need to dynamically change the network in support

of the division commander’s scheme of maneuver. The G-6 derives his authority to control the network

from the division commander; this authority empowers him to utilize all signal equipment and personnel for

the successful completion of his mission. The successful accomplishment of the mission implies that all

signal training requirements are met prior to employment. The G-6 is accountable for all network transport,

network services and the viability of information systems across the force. He controls these network assets

via the NOSCs and utilizes the technical service order; much like the division G-3 uses the FRAGO to

control the maneuver forces under the division.

D-3. The G-6 network responsibilities encompass all the management and control of the entire federation

of networks. The NOSC enables the G-6 to monitor the health of the network in support of the command.

The division G-6 is organized and resourced to provide NETOPS support to the division command posts

(tactical [TAC], main, and mobile command group). The G-6 utilizes NETOPS functions to synchronize

disparate division unit networks into one division information network, as a part of the LWN and GIG. It

should be noted that the NETOPS functions performed in the subordinate support brigades and BCTs

provide a second echelon of NETOPS management that the division G-6 coordinates as part of the greater

NETOPS plan. Figure D-1 provides a recommended G-6 organization.

19 November 2008

FM 6-02.71

D-1

FOR OFFICIAL USE ONLY

Appendix D

G-6

SIGNAL SYSTEM

SSIO

SIGOPS

SUPPORT

SECTION

SIGNAL SYSTEM

NETWORK

PLANS

IDM

SUPPORT

MANAGEMENT

TEAMS

TACTICAL

MESSAGE

COMSEC

CND

SYSTEM

D-4. The G-6 Signal Operations (SIGOPS) Section. The SIGOPS section consists of the NETOPS

functions which includes the network management and the tactical message system cell, IDM, IA, CND,

and COMSEC. In addition the SIGOPS section contains a NETOPS plans cell. The cells within the

SIGOPS section performs the following functions:

Integrates network management, IDM, and IA functions.

Maintains network connectivity across the division, to include units deployed to the AOR, units

en route to the AOR, and units at home station.

Manages the division network from the applications residing on individual platforms through the

points at which the division network connects to the LWN.

Executes deliberate modifications to the division network in order to meet the needs of the

commander.

Manages requirements; accepts, validates and tracks headquarters and subordinate unit

communication requirements (computers, cell phones, radios, etc.).

Monitors network performance.

Manages the quality of service of the services provided through the division network, including

the interoperability of the division network with external networks that are not controlled by the

G-6 (e.g., Global Broadcast Service, Trojan Special Purpose Integrated Remote Intelligence

Terminal, Combat Service Support Very Small Aperture Terminal).

Coordinates satellite access requests (SARs) and deconflict frequencies.

Resolves, reports, and coordinates with other agencies to resolve radio frequency conflicts.

Secures access into the division network and monitors accesses and activities internal to the

network.

D-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Network Management and Operations: Division

D-5. The G-6 Plans Cell. The plans cell is responsible for developing future plans and Annex K to the

order, performing JTF and ASCC coordination, and service provisioning planning for the division. The G-6

plans cell performs the following functions:

Prepares, maintains and updates command information management estimates, plans and orders

to include the Information Management Plan.

ICW the G-3, establishes procedures for employing relevant information and information

systems to develop the common operational picture.

Coordinates, plans, and directs the development of the common operational picture within the

main command post.

Coordinates with staff sections to ensure information quality criteria

(accuracy, timeliness,

usability, completeness, precision, reliability) are maintained.

Coordinates local information network capabilities and services.

Monitors and reports status of information network; coordinates future network connectivity.

Coordinates future command, control, communications, and computer operations interface with

joint, coalition forces to include host nation.

Conducts electromagnetic spectrum operational planning.

Develops and publishes Annex K to the division OPORD.

Plans the transition of responsibility for the tactical network from the division to permanent

theater signal assets (ITSB/ESB or commercial/contract).

D-6.

Signal System Support Section. This section performs the following functions:

Manages the local equipment and facilities that collect, process, store, display, and disseminate

information including computers

(hardware and software) and communications as well as

policies and procedures for their use.

Monitors, manages, and controls organic communications systems that interface with the GIG

Performs TAC NETOPS functions (network management, IDM, IA).

Manages a set of integrated applications, processes and services that provide the capability for

producers and users to locate, retrieve, and send/receive information

D-7.

Signal System Support Teams. These teams, which are part of the signal system support section,

performs the following functions:

Installs, operates, maintains, and defends server data

(SIPRNET) and military Internet

(NIPRNET) in support of division command post operations.

Manages installation and operation of division main and TAC command post LANs, to include

cable/wire installation and troubleshooting.

Installs command post cable and wire; coordinates and supervises team members in the

construction, installation, and recovery of cable and wire communications systems and auxiliary

equipment within division command posts.

Forms a portion of the division Information Service Support Office.

Installs and operates the division’s IT help desk; provides e-mail assistance and other help desk

functions.

Assists division units with network installation and troubleshooting as directed by the G-6.

D-8. The G-6 Signal System Integration Oversight (SSIO) Section. The SSIO section performs the

following functions:

Oversees network certification for division units.

Coordinates and tracks command, control, communications, and computer modernization.

Coordinates and tracks command, control, communications, and computer sustainment

Oversees contractor support.

Coordinates and tracks command, control, communications, and computer maintenance.

Coordinates collective command, control, communications, and computer systems training.

19 November 2008

FM 6-02.71

D-3

FOR OFFICIAL USE ONLY

Appendix D

Training and readiness oversight for BCT JNN teams.

Coordinates communication systems commercialization.

Coordinates division command, control, communications, and computer readiness exercises.

Training and readiness oversight for division headquarters and assigned unit JNN teams.

Supervises data support teams.

Oversees the installation of division command post wire and cable, to include cable system

installation in fixed facilities, which would be probable employment mode as a JTF/JFLCC.

DIVISION G-6 ROLES AND RESPONSIBILITIES

D-9. The G-6 is the principal staff officer for all matters concerning communications and networks. The G-

6 has the technical oversight responsibility over the division information networks to include training and

readiness of the division signal company. The G-6 is responsible for providing planning guidance to the

division signal company to execute the command, control, communications, and computer plan in support

of the division commander’s intent. In executing the commander’s intent, the G-6 directs any technical

changes to the network. To make physical moves to signal equipment, the G-6 recommends FRAGOs to

direct such movement to the G-3. He is responsible for advising the division commander, staff, and

subordinate commanders on command, control, communications, and computer operational matters (staff

responsibilities, technical guidance, and training and readiness responsibility).

STAFF RESPONSIBILITIES

D-10. G-6 staff responsibilities include the following:

Prepares, maintains, and updates command, control, communications, and computer operations

estimates, plans, and orders. Such orders often will cause for CM changes across multiple

brigades.

Monitors and makes recommendations on all technical command, control, communications, and

computer operations.

Acts as the ARFOR G-6 when needed. (Equipment and personnel augmentation may be required

to support this mission.)

Advises the commander, staff, and subordinate commanders on command, control,

communications, and computer operations and network priorities for battle command

(for

example, changing bandwidth allocation to support the division main effort—a brigade

reinforced with additional intelligence, surveillance, and reconnaissance assets).

Directs technical changes to all portions of the division network via the TSO process.

Acts as the JTF J-6, if required. (Equipment and personnel augmentation will be required to

support this mission and will be provided by the theater-level units such as the theater G-6, a

SC(T), or a signal brigade or ASCC as necessary.)

Develops, produces, changes/updates, and distributes signal operating instructions.

Prepares/Publishes command, control, communications, and computer operation's SOPs for

division command posts.

Coordinates, plans, and manages the division’s electromagnetic spectrum operational

environment within its AOR.

Plans and coordinates with higher and lower headquarters regarding information systems

upgrade, replacement, elimination, and integration.

ICW G-2, G-3, and the assistant chief of staff, information operations (G-7), coordinates, plans

and directs all IA activities and command, control, communications, and computer operations

vulnerability and risk assessments.

ICW the staff, actively coordinates with a variety of external agencies to develop the information

and communications plans, manages the information network, obtains required services, and

supports mission requirements.

D-4

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Network Management and Operations: Division

Confirms and validates user information requirements in direct response to the tactical mission.

Establishes command, control, communications, and computer policies and procedures for the

use and management of information tools and resources.

TECHNICAL AUTHORITY RESPONSIBILITIES

D-11. The G-6 technical oversight responsibilities include the following:

Provides signal units assigned or attached to the division with direction and guidance during

preparation of network plans and diagrams establishing the information network

(WAN),

including business and intelligence WANs.

Plans and integrates information systems and battle command equipment due to unit task

organization/reorganization.

ICW the ASCC and JTF, plans and directs all NETOPS activities within the division area of

operations.

Utilizes the NOSC as his eyes and ears to the network, leverages the tools provided by the NOSC

to manage and reconfigure the network as warranted.

TRAINING AND READINESS RESPONSIBILITIES

D-12. Training and readiness responsibilities include the following:

Ensures the development of required skills to all signal personnel within the division area of

operations.

ICW the assistant chief of staff, personnel (G-1), identifies requirements and manages the

distribution of signal personnel within the division.

ICW the G-3, monitors and provides oversight for information dissemination to adjust to

changing warfighting function priorities and control measures within the division area of

operations.

Ensures automation systems and administration procedures for all automation hardware and

software employed by the division are compliant with the GIG procedures and standards or

Army specifications.

Ensures, ICW the special troops battalion command, the division signal company is trained to

support division missions and tasks during home station training events and deployments.

DIVISION NETOPS AND SECURITY CENTER

D-13. The division G-6 employs a fully integrated NOSC providing NETOPS functions for the division. All

division signal elements must coordinate with the NOSC during the engineering, installation, operation,

maintenance, management and defense of the division information network. The division NOSC has overall

responsibility for establishing the division information network and provides the operational and technical

support to all units assigned or attached to the division operating in the division area of operations.

D-14. The division NOSC performs the NETOPS activities, functions, and tasks required to create a

dynamic and responsive network that quickly shifts priorities in order to support the ground tactical plan.

This management function extends the strategic GIG’s capabilities into the responsive, dynamic tactical

formations. In order to increase responsiveness of a complex network and to facilitate the bandwidth

required to support the division headquarters and brigade networks, the division employs a NETOPS cell

with the regional network service center. The regional network service center flattens the TDMA satellite

network structure and increases the bandwidth capability from approximately 6 Mbps to 40 Mbps, while the

embedded NETOPS cell provides the management to enable the division network. The personnel

composition of the NETOPS cell in supporting the network service center is mission, enemy, terrain and

weather, troops and support available-time available and civilian driven.

D-15. In addition to expanding bandwidth, the division has the capability to dynamically reassign the

bandwidth so that the communications support plan can match the division commander’s ground tactical

19 November 2008

FM 6-02.71

D-5

FOR OFFICIAL USE ONLY

Appendix D

plan. An example of this capability is the division designating a BCT as the main effort for an assault. As

the main effort, the division commander gives the BCT a direct unmanned aerial surveillance sensor feed

that must be broadcasted across the entire network. The division G-6 matches the communications support

plan enabling the added, non-organic, capability by allocating a larger segment of the division enabled

bandwidth.

D-16. The division NOSC provides an unprecedented capability that quickly provides capabilities to those

who need it to enable the ground tactical plan. The division NOSC responsibilities include the following:

ICW subordinate organizations, monitors, manages and ensures implementation of enterprise

systems management/network management, IDM/CS, and IA/CND activities.

Provides near real-time awareness of division networks and systems to the division G-6 and

supporting service TNOSC/RCERT.

Coordinates actions to resolve attacks/incidents on the division network with the service TNOSC

and subordinate organizations.

Coordinates operational procedures and requirements for IA/CND and information systems

security with the supporting ASCC RCERT.

ICW division signal company monitors, manages, and controls intra-division information

network components.

Monitors the operation of the networks in the division’s subordinate units.

Provides support and assistance to the subordinate NOSCs as required.

Manages the organizational messaging system of record (Defense Message System, Tactical

Message System) in the division, including managing network addresses and sub-domains.

Coordinates operation and maintenance support of command, control, communications, and

computer systems attached to support deployed division forces with the split-base and reach

operations capability to the home base.

Shares enterprise systems management/network management information with other management

or monitoring centers.

Provides the supporting service TNOSC with near real-time information on the status and

performance of intra-division networks.

Orders and accounts for all forms of COMSEC material, including storing keys in encrypted

form and performing key generation and automatic key distribution.

Performs COMSEC material accounting functions and communicates with other COMSEC

elements.

Performs IDM/CS functions to support all aspects of relevant information dissemination.

Provides near real-time awareness of division networks and system that support the joint

backbone to the JTF JNCC when the division is serving as the ARFOR.

Informs the G-6 of network outages and shortcomings that require the electronic maintenance

shop to rectify.

DIVISION SIGNAL COMPANY ORGANIZATION

D-17. The division signal company is subordinate to the division special troop’s battalion and consists of

the headquarters, G-6 and the signal detachment. In order to ensure the support of the division commander’s

intent, the division signal company installs, operates and maintains the network IAW technical guidance

provided by the division G-6. The division G-6 technical oversight ensures the division network personnel

and equipment are trained and maintained at the levels required to be successful. The organizational

structure for the division signal company is depicted in Figure D-2.

D-6

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Network Management and Operations: Division

DIV SIGNAL COMPANY

HEADQUARTERS

SIGNAL

G-6

DETACHMENT

NETWORK HUB

TAC CP

CABLE

MAIN CP

PLATOON

SECTION

PLATOON

consists of the company headquarters section. The signal detachment links the main command post with

higher, adjacent, and subordinate headquarters and support activities. The signal detachment consists of the

network hub platoon, the TAC command post platoon, a cable section and the main command post platoon.

The elements of the headquarters and the detachment performs the following functions:

Company and detachment headquarters. The company headquarters provides command and

control to the company and is responsible for the administration and logistics support. The

detachment headquarters provides the detachment command and control and limited NETOPS

support.

Network hub platoon. The detachment network hubs, provides TDMA and FDMA satellite

connectivity. The network hub platoon consists of the TDMA and FDMA multiband section, the

Baseband and Hub Support Sections. It installs, operates and maintains the network hub and

satellite connectivity to the GIG.

Main command post platoon. The main support platoon installs, operates and maintains the

JNNs supporting the main command post.

TAC command post platoon. The TAC command post platoon is designed to support the

network services for the CP.

Cable Section. The cable section provides the cable and wiring support for the command posts.

19 November 2008

FM 6-02.71

D-7

FOR OFFICIAL USE ONLY

Appendix E

Brigade Combat Team and Battalion

Network Management and Operations

The BCT performs NETOPS functions to maintain their WAN, LAN, common

services, and information systems. Similar to the division, the BCT is required to

operate its own network without augmentation from higher headquarters. This

includes providing effective network management and IA across all organic

networks. In addition, the BCT provides the organic common services of messaging,

collaboration, storage, and security to its subordinate elements.

BRIGADE COMBAT TEAM MAIN COMMAND POST

E-1. The BCT main command post performs functions similar to the division main. This command post

works future plans and participates with the BCT executive officer during the military decision making

process. The BCT main writes the BCT Annex K and coordinates with higher, adjacent, and subordinate

units during the orders development process.

BRIGADE COMBAT TEAM TACTICAL COMMAND POSTS

E-2. The BCT tactical command post is required to perform similar functions for the commander that the

division tactical command post performed. These functions include the ability to produce FRAGOs and

changes to current operations. The BCT tactical command post is also responsible for conducting all

NETOPS associated with the current mission.

BATTALION NETWORK MANAGEMENT AND OPERATIONS

E-3. The battalion performs limited NETOPS functions and relies heavily on the support of the BCT S-6

for the reception of core common services, directory services, WAN accessibility, and IA. The S-6 staff

performs all the planning and operations associated with the main and tactical command posts at higher

headquarters. The S-6 holds the primary responsibility in developing the battalion Annex K input, LAN

management, and connectivity coordination with the BCT and adjacent units. Figure E-1 displays battalions

connected to the network.

19 November 2008

FM 6-02.71

E-1

FOR OFFICIAL USE ONLY

Appendix F

LandWarNet Information Assurance Architecture

Computer Network Defense View

This appendix presents the CND view of the LIAA. It is based on current best

practices and existing technologies that can effectively counter the current threats to

Army networks and systems. It also describes the overall goal for CND architecture

for the Army, the components required to implement this architecture, as well as the

policy that must be consistently applied across the architecture.

ARMY HIGH-LEVEL CND COMPUTER NETWORK DEFENSE

DESIGN

F-1. As the networks of the Army proliferate and become more intertwined, it has become more difficult

to define an external perimeter at which to place boundary CND components and thereby protect all

systems and networks within. The recommended DID strategy then has become more of a distributed DID

concept, which is composed of the items outlined in the paragraphs below and shown in Figure F-1.

Identity/Access

Management

DISN

(Semi-Untrusted network)

NOSC Network

(Trusted Network)

PKI

IA Management

System

Installation Network

Tactical Network

Authentication

(Trusted Network)

Installation Network

(Trusted Network)

Service

(Trusted Network)

Unit

= IA Component

Figure F-1. Distributed defense in depth decentralized

IA management/components

19 November 2008

FM 6-02.71

F-1

FOR OFFICIAL USE ONLY

Appendix F

DISTRIBUTED DID

F-2. The Army CND perimeter will be a distributed, controlled, somewhat virtual perimeter. The Army

distributed perimeter is defined as any gateway that connects to the DISN, JTF network, or the Internet.

These networks will only be trusted to deliver packets. When packets arrive from these networks at the

Army distributed perimeter, they will not be trusted. The LIAA will deploy perimeter protection at every

connection to the DISN or the Internet. In general, connectivity to the Internet should be provided by the

NIPRNET; however, it is understood that, on occasion, the Army does connect networks to the Internet.

F-3. In the strategic environment, DISN connections are typically implemented at the installation level,

although in the future this may occur at GIG bandwidth expansion sites for many installations. In the

tactical environment, DISN or JTF network connections are typically implemented at echelons above corps,

corps, and division. However, with the fielding of the JNN for the 3ID, the ability to connect to the DISN

will be provided at the unit level.

F-4. The LIAA CND view will provide an additional layer of protection at the enclave level. Enclaves are

networks that are contiguous within installation and tactical networks. For example, a LAN connected to the

installation network and operated by a tenant organization is considered an enclave. A command post LAN

is another example of an enclave. These enclaves are under the authority of one commander/director who is

responsible for protection within his AOR. The LIAA will deploy standard enclave protection at the

gateways between the enclave network and its installation or tactical network.

F-5. The final layer of protection specified by the LIAA CND view is client and server systems’ host

protection. To the extent possible, enterprise-licensed security software and configuration standards will be

used to provide this last layer of defense.

F-6. Management of the LIAA CND view will be centralized to the greatest extent possible. Centralized

IA management of perimeter protection CND components will be performed by the TNOSCs within each

theater. The TNOSCs will be resourced with the necessary tools and skilled personnel to configure,

monitor, and manage these components. TNOSC personnel will also be trained in Army security policy

related to perimeter protection to ensure that Army policy is implemented. The real-time demand of tactical

signal units may require collocation of TNOSC personnel with tactical units to ensure that the commander’s

needs are met in terms of network connectivity and IA. Management of enclave and host protection CND

will be the responsibility of the unit or organization that operates the enclave. Within strategic

environments, it is expected that DOIM will perform this function with TNOSC guidance/oversight. Within

tactical environments, unit signal personnel will perform this function.

F-7. The LIAA CND view specifies that certain IA components will be implemented such that they can

provide services to the entire Army enterprise. For example, AD can provide enterprise-wide identification

and authentication services for Windows platforms. The DOD PKI will be extended into Army tactical

environments to provide the supporting infrastructure for public key enabled (PKE) applications. Enterprise

access management products can provide single sign-on and common Web portal access services for

applications across the Army enterprise. It is the intent of the LIAA CND view to maximize use of these

enterprise-wide services to ensure consistency of implementation across the enterprise.

PERIMETER PROTECTION ARCHITECTURE

F-8. Figure F-1 illustrates the placement of perimeter protection at Army-DISN gateways. A standard

architecture and suite of CND components will be used at every Army-DISN gateway. The primary

objectives of the perimeter protection architecture are to:

Stop intrusion attempts from entering Army networks; prevent malicious code from entering or

leaving Army networks.

Prevent use of frequently used outbound protocols such as the DNS, HTTP, and Simple Mail

Transfer Protocol (SMTP) from being exploited by Trojan horse.

Prevent the download of malicious mobile code through browsers.

F-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

Prevent the use of objectionable Web sites for non-business purposes.

Monitor packets entering or leaving Army networks to detect if any of these unauthorized

activities are occurring.

F-9. To counter these threats, the LIAA CND view specifies the implementation of demilitarized zones at

Army-DISN gateways. The demilitarized zone will host all publicly accessible systems for a particular

installation or tactical network. This would include Web and e-mail servers primarily, but could also allow

for the relocation of File Transfer Protocol (FTP) or other servers generally considered to expose a network

to external threats. Limiting network traffic flow from anonymous users on the NIPRNET or Internet-to-

Web, e-mail, or FTP servers on the demilitarized zone restricts the number of target systems potential

attackers can attempt to exploit. Army administrators can then focus their host protection efforts on securely

maintaining these few servers on the demilitarized zone.

F-10. Figure F-2 illustrates the architecture for a standard Army demilitarized zone. The CND components

that will be implemented as part of the standard perimeter protection architecture are firewalls, gateway

anti-virus scanners, screening Web proxies, and network intrusion detection system (NIDS) devices. The

purpose of the gateway anti-virus scanner at the perimeter is to provide anti-virus detection for the most

common traffic traversing the demilitarized zone: Web

(HTTP, HTTP with Secure Sockets Layer

[HTTPS]), e-mail, and FTP. Centralized management of the anti-virus scanner will improve the Army’s

ability to defend against new viruses by providing a central point where virus definition updates can be

quickly applied.

DISN

Internet

NIPRNET

(GIG-BE)

DMZ

APC

TNOSC

APC LAN

THSDN

APC LAN

JTRS

WIN-T

LAN

Regional

Servers/

GCSS-A

Servers

TOC LAN

Servers

TOC LAN

Mgmt LAN

Installation

System

TAC Internet

Management

Installation

Servers

Network

SATCOM

FBCB2

Desktops

Current Force

Current Force -

DOIM Servers

BCT

OIF/OEF

Digitized

Figure F-2. Perimeter protection placement

F-11. The purpose of the screening Web proxy or Web security device is to examine outgoing Web traffic

and ensure that it is valid HTTP or HTTPS traffic. These devices prevent the use of HTTP/HTTPS as a

tunneling protocol for Trojan horses. In addition, these devices can maintain a list of objectionable Web

sites and block user access to these sites, resulting in greater network bandwidth efficiency. Finally, the

19 November 2008

FM 6-02.71

F-3

FOR OFFICIAL USE ONLY

Appendix F

Web security device can perform content filtering, which provides the ability to scan for sensitive

keywords. This process can help ensure that sensitive information is not being exfiltrated from Army sites.

F-12. Firewalls, or in the future, IPSs, are used in the perimeter protection architecture to control network

traffic flow based on a centrally controlled security policy. NIDS devices will also be deployed on the

demilitarized zone. NIDS will provide the ability to detect intrusion activities that originate from the DISN

or Internet. By placing the NIDS on the demilitarized zone segment, the number of alerts generated by the

NIDS should be significantly reduced because the firewall will be blocking most network protocols. (See

Figure F-3.)

External Network

DMZ

Perimeter Protection Architecture

Public Web

VPN

Server

Concentrator

Network

Intrusion

Web

Public

Antivirus

Detection

Proxy

E-mail

FTP

Firewall

System

Server

Intranet

Figure F-3. Perimeter protection architecture

F-13. In addition to external access to the public demilitarized zone, the perimeter protection architecture

will support the implementation of Army extranets. Extranets are site-to-site connections that will use the

DISN or Internet as the communications backbone for the connection. Figure F-4 illustrates two examples

of Army extranet connections. The first example shows a desktop Global Combat Support System-Army

client system on one installation network accessing a Global Combat Support System-Army server on

another installation’s network. In this case, the NIPRNET is used to provide the connection between the two

installations. The perimeter protection at the client system’s installation will enforce a policy that allows the

client system to access only the Global Combat Support System-Army server within the other installation’s

network. The perimeter protection at the server’s installation will allow only that client system to access the

server.

F-14. In the second example, a current force unit and a digitized unit are operating within an area of

operations. In this case, the SIPRNET is used to provide the connection between the two units. The

perimeter protection at the digitized unit gateway will enforce a policy that allows a command and control

system on the current force network to access only the command and control system within the digitized

unit’s network. The perimeter protection at the current force gateway will allow only the command and

control system on the digitized unit network to access its command and control system.

F-4

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

Extranet Connection Examples

DISN

Internet

NIPRNET

(GIG-BE)

DMZ DMZ

DMZ

DMZ DMZ

APC

TNOSC

APC LAN

THSDN

APC LAN

JTRS

WIN-T

LAN

TOC LAN

Mgmt LAN

TOC LAN

Installation

System

Management

Installation

Servers

Network

SATCOM

FBCB2

Desktops

Current Force

Current Force -

DOIM Servers

BCT

OIF/OEF

Digitized

Figure F-4. Extranet connection example

F-15. Access for extranet connections will be permitted or denied by perimeter protection firewalls. In

some cases, the additional protection of encrypted communications between Army sites may be desired by a

commander or director. The perimeter protection architecture will be capable of providing site-to-site VPN

encryption. These site-to-site VPN connections can be implemented using Internet Protocol Security that is

performed by the firewall. The VPN end points will be the respective sites’ firewalls to allow the NIDS

devices at those sites to monitor network traffic coming from the extranet connection.

PERIMETER PROTECTION ARCHITECTURE

F-16. The following sections discuss the implementation of public access policy and extranet policy within

the perimeter protection architecture.

Public Access Policy

F-17. The public access policy refers to the firewall access control policies that apply to perimeter

protection demilitarized zones. These policies will be applied enterprise wide at all Army sites. These

policies will be controlled by the CIO/G-6 and will require CIO approval to modify. This central control is

necessary because public access presents the greatest risk to the Army enterprise. Public access in this case

is defined as any anonymous packet that originates from the DISN or Internet and is allowed to enter the

demilitarized zone. For example, contractors accessing AKO, family members accessing unit Web sites,

mobile users accessing VPN concentrators, and e-mails from friends, families, and business partners are

19 November 2008

FM 6-02.71

F-5

FOR OFFICIAL USE ONLY

Appendix F

examples of connections from anonymous hosts that require access to Army networks and resources. Figure

F-5 illustrates the public access policy overlaid onto the perimeter protection architecture.

F-18. The Public Access Policy specifies that the following protocols will be permitted from anonymous

DISN and Internet IP addresses to the demilitarized zone servers (Unless specifically mentioned, all other

protocols will be denied access by the firewall)—

HTTP will be permitted from anonymous IP addresses to public Web servers on the

demilitarized zone.

HTTPS will be permitted from anonymous IP addresses to public Web servers on the

demilitarized zone.

SMTP will be permitted from anonymous IP addresses to public e-mail servers on the

demilitarized zone. This type of network traffic will be routed through the gateway’s anti-virus

device before it is sent to public e-mail servers.

If external FTP services are required, then FTP is permitted from anonymous IP addresses to

public FTP servers on the demilitarized zone.

If remote users require VPN access to a VPN concentrator, then Internet Protocol Security (IP

protocol

50), Internet Key Exchange

(User Datagram Protocol port

500 and 4500), and

Authentication Header (IP protocol 51) are permitted from anonymous IP addresses to VPN

concentrators on the demilitarized zone.

No protocols will be permitted from demilitarized zone servers to the external network.

Allow Only

HTTP

HTTPS

External Network

SMTP

FTP (optionally)

IPSECIKE (optionally)

Perimeter Protection Architecture

DMZ

Public Web

VPN

Server

Concentrator

Allow Only

Authenticated

HTTP

DNS Queries

Network

Intrusion

Antivirus

Detection

Web

Public

Firewall

System

Proxy

E-Mail

FTP

Server

Allow Only

Web Application Protocols

Web content push

Intranet

SMTP

FTP file push

VPN Concentrator Connections

Figure F-5. Perimeter protection—public access policy

F-19. The Public Access Policy specifies that the following protocols will be permitted from demilitarized

zone servers to servers within the internal network (Unless specifically mentioned, all other protocols from

the demilitarized zone to the internal network will be denied by the firewall)—

If the public Web server on the demilitarized zone hosts active content, the Web server may

connect to application servers on the internal network using the minimum required protocols to

implement the connection. Examples of these protocols may be Netscape Application

Programming Interfaces, Java 2 Platform Enterprise Edition, and .NET protocols.

SMTP will be permitted from the e-mail server on the demilitarized zone to e-mail servers on the

internal network.

F-6

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

If a remote access VPN concentrator resides on the demilitarized zone, then a limited set of

protocols will be permitted from the VPN concentrator to the internal network. These protocols

include Post Office Protocol and Internet Message Access Protocol for e-mail; HTTP and

HTTPS for Web; Telnet and FTP for system administrators; Lightweight Directory Access

Protocol for Windows AD login; and Network Basic Input/Output System protocols for

Windows Networking.

F-20. The Public Access Policy specifies that the following protocols will be permitted from servers within

the internal network to demilitarized zone servers (Unless specifically mentioned, all other protocols from

the internal network to the demilitarized zone will be denied by the firewall)—

The Secure Shell Protocol will be used to push Web content to the public Web server. Secure

Shell will be permitted from the internal network to the public Web server on the demilitarized

zone.

The Secure Shell Protocol will be used to push files to the public FTP server. Secure Shell will

be permitted from the internal network to the public FTP server on the demilitarized zone.

F-21. The Public Access Policy specifies that the following protocols will be permitted from the internal

network to the external network (Unless specifically mentioned, all other protocols from the internal

network to the external network will be denied by the firewall)—

DNS will be permitted from internal DNS servers to DISN or Internet Service Provider DNS

servers. This will allow name resolution of external IP addresses.

HTTP and HTTPS will be permitted from internal network IP addresses to the external network.

These protocols will be routed through the Web proxy to provide Web security.

Extranet Access Policy

F-22. Extranet Access Policy refers to the firewall access control policies that apply to Army site extranet

connections. These policies will be implemented by the TNOSCs but specified by the local site’s

commander or director. TNOSC personnel will provide advice to commanders/directors to help them

decide which protocols present an acceptable level of risk. The policies specified herein provide guidelines

for TNOSC personnel on implementing the Extranet Access Policy. Figure F-6 illustrates the Extranet

Access Policy overlaid onto the perimeter protection architecture.

19 November 2008

FM 6-02.71

F-7

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

F-23. The following is a summary of the Extranet Access Policy:

Extranet connection rules should limit the number of permitted source IP addresses to the

minimum number of hosts required to implement the extranet connection. Rules that allow entire

subnets to access an extranet connection are discouraged.

Extranet connection rules should limit the number of permitted destination IP addresses to the

minimum number of hosts required to implement the extranet connection. Rules that allow

source IP addresses to access entire subnets are discouraged.

Extranet connection rules should limit the number of permitted protocols to the minimum

required to implement the extranet connection.

The use of remote execution protocols should be discouraged. Remote execution protocols are

protocols that allow users to execute commands on a remote system. Potential attackers can use

these protocols to leapfrog from system to system and site to site.

The use of certain Internet Control Message Protocols over extranet connections such as echo-

request and echo-reply should be discouraged to prevent denial-of-service attacks.

SMTP or Microsoft Exchange should not be permitted through an extranet connection. Mail

server connections should be performed through the public e-mail server so that the gateway

anti-virus device can scan incoming and outgoing e-mail messages. Allowing e-mail exchanges

through the extranet connection will bypass the anti-virus scanner and could facilitate the spread

of malicious code carried by e-mail.

ENCLAVE PROTECTION ARCHITECTURE

F-24. Figure F-7 illustrates the placement of enclave protection at command post LANs and installation

enclaves. A standard architecture and suite of CND components will be used at every gateway between

command post LANs and Army tactical networks or tenant organization LANs and installation networks.

The primary objectives of the enclave protection architecture are to stop insider intrusion attempts, prevent

the spread of malicious code through Army networks, prevent denial-of-service attacks that originate from

within Army networks, and monitor packets entering or leaving enclaves to detect if any of these

unauthorized activities are occurring.

19 November 2008

FM 6-02.71

F-9

FOR OFFICIAL USE ONLY

Appendix F

DISN

INTERNET

NIPRNET

(GIG-BE)

DMZ

DMZ DMZ DMZ

APC

TNOSC

APC LAN

THSDN

JTRS

WIN-T

APC LAN

LAN

Regional

Servers/

GCSS-A

Mgmt LAN

Servers

TOC

TOC LAN

Installation

LAN

Management

System

Installation

System

Installation

Servers

Network

SATCOM

Tac Internet

Desktops

FBCB2

DOIM

Servers

Current Force

Current Force -

Servers

BCT

OIF/OEF

Digitized

Figure F-7. Enclave protection placement

F-25. Figure F-8 illustrates the CND components used in the enclave protection architecture. The

architecture consists of firewalls, or in the future, IPSs and NIDSs. The firewalls are used in the enclave

protection architecture to control network traffic flow based on a locally controlled security policy. NIDS

devices will provide the ability to detect intrusion activities, worms, and Trojan horses that originate from

within Army networks. By placing the NIDS on the enclave LAN interface of the firewall, the number of

alerts generated by the NIDS should be significantly reduced because the firewall will be blocking most

network protocols. The use of NIDS in some tactical circumstances is optional. For small deployments

where unit-trained personnel are not available to operate the NIDS, the unit may decide to forego use of

NIDS on command post LANs. However, a NIDS must always be used as part of the perimeter protection

architecture. For installations, it is expected that enclave protection will be managed by the TNOSCs with

input on policy from local commanders/directors and their staff.

F-10

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

Installation or Tactical Network

Enclave Protection

Firewall or

IPS

NIDS

Enclave Network

Figure F-8. Enclave protection architecture

Enclave Access Policy

F-26. Enclave Access Policy refers to the firewall access control policies that apply to Army enclave-to-

enclave connections. These policies will be implemented by the TNOSCs but specified by the local site’s

commander or director. TNOSC personnel will provide advice to commanders/directors to help them

decide which protocols present an acceptable level of risk. The policies specified herein provide guidelines

for TNOSC personnel on implementing Enclave Access Policy. Figure F-9 illustrates the Enclave Access

Policy overlaid onto the enclave protection architecture.

F-27. The following is a summary of the enclave protection policy:

Enclave connection rules should limit the number of permitted source and destination IP

addresses to the minimum number of hosts required to implement the enclave-to-enclave

connection.

Enclave connection rules should limit the number of permitted protocols to the minimum

required to implement the enclave-to-enclave connection.

The use of remote execution protocols should be discouraged. Potential attackers can use these

protocols to leapfrog from enclave to enclave.

The use of certain Internet Control Message Protocols over extranet connections such as echo-

request and echo-reply should be discouraged to prevent denial-of-service attacks.

19 November 2008

FM 6-02.71

F-11

FOR OFFICIAL USE ONLY

Appendix F

INTRANET

Allow Only

IP Address and/or

Specific Protocols

Between Enclaves

Enclave Protection

Firewall or

NIDS

Firewall or

NIDS

IPS

Enclave

Network

Figure F-9. Enclave protection policy

HOST PROTECTION

F-28. The final protection level in the LIAA CND view is the host protection level. It is the goal of the US

Army to employ host-based IDS software, anti-virus software, personal firewall software, and patch

management agents on all workstations and servers. In addition, critical servers should implement file

integrity tools as well. The Army has enterprise licenses for both personal firewalls and anti-virus software

through the DOD. Because of the availability of these enterprise licenses, the Army can deploy these

applications on every system. However, with host-based IDS devices, file integrity tools, and patch

management software, there may not be the same latitude. It would be optimal for the Army to acquire

enterprise licenses for these applications, but if that is not financially feasible, choices must be made

regarding which systems will be configured with host-based IDS software and patch management agents. It

may be necessary to initially configure only critical servers, such as demilitarized zone servers and data

center servers, with this software if there is a limited license. In addition to host protection software, Army

host system protection will be accomplished by:

Implementing relevant security patches as defined by IAVAs.

Secure configuration of operating systems using DOD and Army Security Technical

Implementation Guides (STIGs) http://iase.disa.mil/stigs/stig/index.html

Secure configuration of database management systems using DOD and Army STIGs.

Secure configuration of standard applications, such as Web servers, using DOD and Army

STIGs.

Strong password/authentication for Windows networking using AD.

Use of enterprise IA services, such as Common Access Card, PKI, and PKE applications.

F-29. While most users will access resources locally using Smartcard-based Logon, mobile and home users

may use non-Army systems to remotely access e-mail and other enterprise services. Because these systems

may not be configured to Army standards, the access granted to these systems will be limited. It is expected

F-12

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

that these users will access Army enterprise services through remote access VPNs. In the future, the Army

may consider using emerging commercial products that check host systems for patches, personal firewall

activation, and anti-virus update status prior to allowing a connection to the network.

CENTRALIZED IA SERVICES

F-30. The LIAA CND view specifies that certain IA services will be implemented so they can provide

services to the entire Army enterprise. This will ensure consistency of implementation across the enterprise

while reducing the overall cost of implementing these services. In reality, some of the services may be

provided at the DOD level by DISAs Net-Centric Enterprise Services program. It is anticipated that the

following core services are to be implemented in Net-Centric Enterprise Services Increment 1:

Single sign-on.

Role-based access control.

Data/eXtensible Markup Language/Simple Object Access Protocol classification labeling.

F-31. The enterprise IA services provided by the Army are intended to be in addition to Net-Centric

Enterprise Services, and will only be developed in response to unique Army IA requirements. The following

services are needed to fulfill Army unique needs:

PKI. The DOD PKI provides the necessary infrastructure to support PKE applications. This

includes key generation facilities, directory services, Common Access Card tokens, registration

authorities, compromise recovery capabilities, and key recovery capabilities. This infrastructure

primarily exists in strategic environments. The Army is just beginning to examine extending PKI

support into the tactical environment.

AD. The Army is migrating to AD in order to provide a number of centralized services for

Windows systems. With the migration to AD, the following security-relevant services will be

available to Army systems: strong Kerberos-based authentication, group policy management that

can be used to implement STIGs and patches, and some secure directory services. AD is more

prevalent in the strategic environment, but the Army is actively pursuing implementation in the

tactical environment.

Single sign-on. Currently, AKO provides single sign-on authentication for multiple applications.

It is envisioned that this service could be extended to other Web portals that are hosted on Army

public Web servers. Additional activity should be focused on consolidating Army Web

applications into portals that provide users access to multiple applications through a single login.

This will enhance the Army’s ability to centrally manage IA at these portals with the added

benefit of relieving users of the need to login to multiple applications.

CENTRALIZED IA MANAGEMENT

F-32. The key to the concept of CND is real-time IA management. This includes the ability to configure

CND components, monitor IA sensors, and provide the analysis necessary to properly react in the event of

an attack. The benefits of a centralized approach are that it ensures consistency of IA implementation across

the enterprise IAW Army IA standards and minimizes the number of personnel with the highly specialized

skills needed to perform IA. Table F-1 summarizes the roles and responsibilities related to IA management

of specific LIAA CND protection levels.

19 November 2008

FM 6-02.71

F-13

FOR OFFICIAL USE ONLY

Appendix F

Table F-1. IA management responsibilities of LIAA CND protection levels

Protection level

Responsible organization

Perimeter Protection—

CIO/G-6 determines public access policy.

Public Access

TNOSC manages perimeter protection CND

components within a theater.

Perimeter Protection—

Local commander/director for installation or tactical

Extranet Access

unit determines extranet access policy, with

guidance from TNOSC IA personnel.

TNOSC manages perimeter protection CND

components within a theater.

Enclave Protection

Local commander/director for enclave determines

enclave access policy, with guidance from TNOSC

IA personnel.

TNOSC manages enclave protection CND

components within a theater. At the discretion of

the commander, signal personnel within a unit may

take over this responsibility.

Host Protection

Local commander/director for enclave has overall

responsibility for host protection implementation

and compliance.

At installations, DOIM will manage host protection.

Centralized IA Services

Net-Centric Enterprise Services, which will include

the DOD PKI, is managed by DISA. AKO and AD is

managed by NETCOM.

F-33. The following IA management functions will be performed by the TNOSCs/RCERTs:

IA event monitoring and correlation. While commanders and installations will still have the

ability to view IA activity, they will not be responsible for providing IA event monitoring and

event correlation. The TNOSC will collect data from perimeter protection and enclave protection

CND components. Due to the size and complexity of the LWN, the TNOSC will employ security

information management tools to provide event monitoring, event correlation, and data reduction

support for analysts.

Incident response. When an IA event is detected, the TNOSC will work with the collocated

RCERT to resolve IA incidents. Events of interest identified by analysts performing IA event

monitoring will be investigated from the RCERT ICW the TNOSC. If the response involves a

centrally managed CND component, the TNOSC will coordinate with CIO/G-6, unit

commanders, installation commanders/directors, and enclave commanders/directors and take

actions to counter the attack. These actions may include changing firewall policies, applying

patches, restricting Web access, or removing systems from the network. If the response involves

a locally managed LAN, the TNOSC will work with local administrators. The RCERT will also

coordinate with the ACERT to publish significant information to interested parties.

VPN management. TNOSCs will manage VPN hardware and software. This includes extranet

VPNs and remote access VPNs. Under certain circumstances, tactical VPNs between enclaves

may require local management (i.e., where connectivity to a TNOSC is not possible). However,

F-14

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

under normal conditions, the TNOSC service desk will manage the provisioning of VPN services

between various installations, between the APCs, and between installations and the APCs.

IA system/Device management. All CND components (i.e., firewalls, IPS, NIDS, gateway anti-

virus, and gateway Web security devices) will be managed from the TNOSC. Management

includes CND components at the perimeter and enclaves. Management functions include CM of

firewall policies, CM of CND component software, pushing updates of anti-virus definition files

to gateway anti-virus devices, pushing updates of attack signatures to NIDS devices, pushing

updates of objectionable Web sites to Web security devices, and maintaining CND component

hardware.

Formal communications. As the Army transitions to a centralized IA management construct, a

formal communications process will be implemented between commanders and the TNOSC. The

individual commanders must have a way to communicate information regarding their networks to

the individuals now tasked with monitoring and managing the IA devices on those networks. This

includes strategic as well as tactical environments. Without this type of interaction, the TNOSC

will be working in a void, with limited information regarding the network they are trying to

protect. The input by commanders to the TNOSC/RCERT will provide significant and critical

information about the environment being monitored, allowing for more accurate determination of

security events.

Secure configurations guidance. STIGs are provided to the A-GNOSC by DISA for use on

Army systems. The configurations then become part of the Army Golden Master Program. The

A-GNOSC uses the distribution network of the TNOSC to provide this information. All STIGS

are published from the TNOSC, although actual hands-on configuration is performed by local

administrators. Configurations are allocated through the Systems Management Function, as

needed, to installations and tactical units. Some tactical systems are exempt from this

configuration control.

Vulnerability assessments. As part of the system life cycle, vulnerability assessments will be

performed on workstations and servers to ensure that they remain secure. Computer Defense

Assessment Program assistance can be requested from the servicing RCERT.

F-34. The tools required by the TNOSC to perform these functions are firewall enterprise management

systems, security information management systems, security compliance management software, network

vulnerability scanners, asset inventory software, and network discovery software. Only those IA tools

approved by National Security Agency/DISA will be used.

F-35. The following IA management functions will be directed by commanders and directors and

implemented by the DOIM in strategic environments and signal personnel in tactical environments. The

tools required by DOIM and signal personnel to perform these functions are firewall enterprise management

systems, security compliance management software, network vulnerability scanners, and network discovery

software. IA management function include:

Formal communications. As mentioned above, IA device management will be the responsibility

of the TNOSC. For extranet and enclave access policies, commanders and directors will need to

communicate with TNOSC personnel to develop these policies. A formal communications

methodology will be developed to facilitate this communication. In some cases, the

communications mechanism may consist of collocating TNOSC personnel with the unit during

tactical deployment or to installations.

IA system/device management. Host protection software will be managed locally. The local

commander or director will ensure that software is loaded and configurations are managed and

updated as defined by Army standards or IAVAs.

Secure configurations guidance. The local commander or director at strategic sites will ensure

that hosts under their purview are configured IAW Army-published STIGs. For tactical systems,

the acquisition organization (e.g., PEO, program manager) responsible for acquiring the system

will ensure that hosts under their purview are patched IAW Army published STIGs.

19 November 2008

FM 6-02.71

F-15

FOR OFFICIAL USE ONLY

Appendix F

Patch management. The local commander or director at strategic sites will ensure that hosts

under their purview are patched IAW published IAVAs. For tactical systems, the acquisition

organization responsible for acquiring the system will ensure that hosts under their purview are

patched IAW published IAVAs.

Vulnerability assessments. As part of a proactive IA program, the local commander or director

may authorize vulnerability assessments on workstations and servers to ensure that they are in

compliance with IAVAs and STIGs. The local commander or director should coordinate with

TNOSC personnel so that vulnerability assessment activities are not treated as intrusion events.

IA/CND TRAINING REQUIREMENTS

F-36. The following paragraphs discuss IA/CND training requirements.

USER TRAINING

F-37. To support the Soldier in a highly effective and professional manner, the Army must ensure that

appropriate levels of IA awareness, training, education, certification, and workforce management are

provided to the IA workforce and information system users that commensurate with their respective

responsibilities.

F-38. Users are the foundation of the DID strategy, and their actions affect the most vulnerable portion of

the AEI. Users must hold a security clearance or access approvals commensurate with the level of

information processed or available on the system. All users must receive an Initial Security Awareness

Briefing training tailored to the system and information accessible before issuance of a password for

network access. Users must have training in security awareness annually thereafter. The Initial Security

Awareness Briefing will include the following:

Threats, vulnerabilities, and risks associated with the system. This portion will include specific

information regarding measures to reduce malicious logic threats; principles of shared risk,

external and internal threat concerns; acceptable use privacy issues prohibitions on loading

unauthorized software or hardware devices; and the requirement for frequent backups.

Information security objectives (that is, what needs to be protected).

Responsibilities and accountability associated with IA.

Information accessibility, handling, and storage considerations.

Physical and environmental considerations necessary to protect the system.

System data and access controls.

Emergency and disaster plans.

Authorized system configuration and associated CM requirements.

Incident, intrusion, malicious logic, virus, abnormal program, or system response reporting

requirements.

INFOCON requirements and definitions.

IAM TRAINING

F-39. IAMs are appointed at all appropriate levels of command. This includes major subordinate

commands and generating and deploying forces

(usually the division G-6). The IAM has overall

responsibility for the unit’s IA program to include project development, deployment, and management of

unit software, operating systems, and networks. The IAM must be IA trained and certified, and must

maintain his certification. All IAMs will hold a US government security clearance and access approval

commensurate with the level of information processed by the system. A contractor will not fill the IAM

position. Units will designate the IAM position IT-I, IT-II, or IT-III. Table F-2 provides the minimum IAM

training requirements.

F-16

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

Table F-2. IAM training requirements

Step

IAM training requirements

Complete Initial Security Awareness Briefing.

Be appointed, on orders, as unit IAM.

Complete one of the following within 6 months of appointment:

The four day Army IAM course.

The e-Learning (SmartForce) modules in Information System.

The e-Learning (SmartForce) modules in Internet Security.

Other Service or commercial vendor courses.

Complete/Attend one of the following every 18-24 months:

A four-day Army IA workshop or a DOD-sponsored IA workshop.

The e-Learning (SmartForce) modules Securing Networked Information I or Securing

Networked Information II.

The e-Learning (SmartForce) modules Microsoft or Unix.

Other Service or DOD IA workshops.

Annotate all training and training refresher in the Compliance Reporting Database Second Edition

(A&VTR) within two weeks of course completion.

IANM/INFORMATION ASSURANCE NETWORK OPERATOR TRAINING

F-40. The commander of the unit responsible for the network appoints the IANM. The IANM is normally

under the OPCON of the S-3. Units will appoint information assurance network operators (IANOs), as

required, to assist the IANM. Units will designate IANM and IANO positions IT-I or IT-II. Each IANM

and IANO must be IA and Vulnerability Assessment Technician certified. Table F-3 describes the minimum

training requirements necessary to be appointed to an IANM or IANO position.

Table F-3. IANM/IANO training requirements

Step

IANM/IANO training requirements

Complete Initial Security Awareness Briefing.

Be appointed, on orders, as unit IANM or IANO.

Complete one of the following within 6 months of appointment:

The four-day Army IAM Course.

The e-Learning (SmartForce) modules in Information System Security.

The e-Learning (SmartForce) modules in Internet Security.

Other Service or commercial vendor courses.

Complete the 2 week Systems Administrator/Network Manager course within 6 months of

appointment.

Complete/Attend one of the following every 18-24 months:

A four day Army IA workshop or a DOD sponsored IA workshop.

The e-Learning (SmartForce) modules Securing Networked Information I or

Securing Networked Information II.

The e-Learning (SmartForce) modules Microsoft or UNIX.

Other Service or DOD IA workshops.

Annotate all training/training refresher in A&VTR within two weeks of course completion.

19 November 2008

FM 6-02.71

F-17

FOR OFFICIAL USE ONLY

Appendix F

IASO TRAINING

F-41. The commander of the activity responsible will appoint an IASO (normally the unit’s signal officer)

for each information system or group of information systems that connect to the network. The G-6/S-6 has

overall responsibility for the secure operation of the network and information systems at BCT and

subordinate units. This function is performed by the DOIM or DOIMs representative in the generating and

deploying forces. At the BCT, the G-6/S-6 normally assumes the role and responsibilities of the IASO.

Table F-4 outlines the IASO training requirements.

SYSTEM ADMINISTRATOR/NETWORK MANAGER TRAINING

F-42. System administrators and network managers must be designated as IT-I, IT-II, or IT-III. Each

system administrator/network manager must be trained, experienced, and currently certified on the

information system they are required to maintain. The system administrator/network manager should be a

US citizen. He must hold a US government security clearance and local access approvals commensurate

with the level of information processed on the system or network. Table F-5 lists the system

administrator/network manager training requirements.

Table F-4. IASO training requirements

Step

IASO training requirements

Complete Initial Security Awareness Briefing.

Be appointed, on orders, as unit IASO.

Complete one of the following within 6 months of appointment:

IASO Course.

DISA’s Operational Information System Security compact disk-read only memory

(CD-ROM).

The e-Learning (SmartForce) modules in both Internet Security and Net Safety.

Other Service or commercial vendor courses.

Complete/Attend one of the following every 18-24 months:

A four day Army IA workshop or a DOD sponsored IA workshops.

The e-Learning (SmartForce) modules Securing Networked Information I or

Securing Networked Information II

The e-Learning (SmartForce) modules Microsoft or UNIX.

Other Service or DOD IA workshops.

Annotate all training/training refresher in the A&VTR within two weeks of course

completion.

INFORMATION ASSURANCE VULNERABILITY MANAGEMENT

F-43. IAVM is the DOD program to identify and resolve discovered vulnerabilities in Army systems and

platforms. It requires the completion of four distinct phases to ensure compliance. These phases are (1)

vulnerability identification, dissemination, and acknowledgement; (2) application of measures to affected

systems to make them compliant; (3) compliance reporting; and (4) compliance verification. This program

includes IAVAs, IAVBs, and technical advisories.

F-44. A patch is an immediate solution provided to users once a bug is discovered and can often be

downloaded from the software maker's Web site. Previously, patches required a manual touch at each

device on the network coupled with the length of time an automated tool was required. An enterprise

solution has been selected by DOD which is eEye Retina for scanning and Citadel Hercules for remediation.

F-45. Complete asset inventories (100 percent) will be conducted and reported to the A&VTR semi-

annually as a minimum and after every IAVA. Every system administrator/network manager will register in

F-18

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

the A&VTR and record training as well as the assets for which they are responsible. Dissemination of IA

technical tips, IAVBs, and IAVAs will automatically be forwarded upon registration completion.

Interoperability testing will be performed prior to the application of system patches and fixes for

interoperability compliance.

F-46. All IAVAs will be applied immediately. If the IAVA cannot be implemented, a mitigation plan must

be submitted in A&VTR for approval/disapproval.

Table F-5. System administrator/Network manager training requirements

Step

System administrator/Network manager training requirements

Complete Initial Security Awareness Briefing.

Be appointed, on orders, as unit SA or network management.

Complete one of the following within 6 months of appointment:

The four-day Army IAM Course.

The e-Learning (SmartForce) modules in Information System Security

The e-Learning (SmartForce) modules in Internet Security.

The IASO course.

DISA’s Operational Information System Security CD-ROM.

The e-Learning (SmartForce) modules in both Internet Security and Net Safety.

Other Service or commercial vendor courses.

Complete the ten day technical System Administrator/Network Manager Course (Level II)

within six months of appointment and maintain a record of the completion date.

Complete/Attend one of the following every 18-24 months:

A four day Army IA workshop or a DOD sponsored IA workshop.

The e-Learning (SmartForce) modules Securing Networked Information I or

Securing Networked Information II.

The e-Learning (SmartForce) modules Microsoft or UNIX or any Microsoft

module.

Other Service or DOD IA workshops.

SCANNING AND REMEDIATION

F-47. The paragraphs below discuss scanning and remediation.

Scanning

F-48. Scanning is the gathering of information on information systems and device configurations, which

may be used for system identification, maintenance, security assessment and investigation, vulnerability

compliance, or compromise. This includes network port scanning and vulnerability scanning, whether wired

or wireless, classified or unclassified. Scanning is conducted throughout all phases of operation (phases 0-

4).

F-49. An operational scanning capability will be retained at the unit level as well as layered throughout the

enterprise operational management structure for all classifications of networks. Regular, scheduled, and no-

notice scans are integral to Security Policy and Compliance Enforcement and shall be done at all levels and

all operational networks. Scanning tools may be obtained through Communications Security Logistics

Activity.

19 November 2008

FM 6-02.71

F-19

FOR OFFICIAL USE ONLY

Appendix F

F-50. Assessors must use a five-step methodology for assessment scanning as follows: identify assets,

determine vulnerabilities, review vulnerabilities, remediate vulnerabilities, and validate remediation

measures. All new information systems and device vulnerabilities must be proactively managed.

F-51. System administrators/Network managers must identify and prioritize which systems are most critical

and develop a protection strategy. System administrators/Network managers and IA personnel will perform

routine and scheduled unit vulnerability assessments and management in addition to IAVM procedures to

manage system and network vulnerabilities proactively, and to maintain the necessary skill sets to remediate

vulnerabilities proficiently, whether these networks reside with generating or deployed forces. Table F-6

details the actions that must be conducted when scanning.

Remediation

F-52. The system administrator/network manager will ensure the confidentiality of information by

preventing unauthorized individuals access to computer equipment. The system administrator/network

manager will patch system security vulnerabilities on all Army platforms. DOIM and tactical unit

administrators are required to validate patches whether on the installation network or placed in storage.

These requirements should be stated in unit OPORDs and other directives with command.

Table F-6. Scanning guidelines/actions

Step

Scanning guidelines/actions

System administrator will obtain and maintain training and certification on Army-approved

IA scanning tools from Communications Security Logistics Activity located at

https://informationassurance.us.army.mil/.

System administrator will review Army Best Business Practices at

https://informationassurance.us.army.mil.

System administrator will scan network-attached devices with Army approved products

monthly or after receipt of an IAVA.

System administrator will review scans report and determine devices to be patched.

Update locally created database/spreadsheet for future reference on false positives.

IASO and system administrator will manually or electronically remediate devices requiring

patch.

IASO and system administrator will rescan network for patch verification.

IASO and system administrator will maintain scan results locally and report scan results

to the organization commander and IA personnel, DOIM and servicing NETCOM and

information management area component, RCIO, functional CIO, RCERT/TNOSC, or

ACERT/A-GNOSC.

IASO and system administrator will update A&VTR with compliancy information.

F-53. System administrators are responsible for reducing the vulnerability of their system through the

application of software patches, both hot fixes and service packs. Table F-7 details the actions taken during

the remediation process.

F-20

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

LandWarNet Information Assurance Architecture

Computer Network Defense View

Table F-7. Remediation actions

Step

Remediation actions

Implement unit policy directing, on a weekly basis, users log off their work stations but

leave work stations on for application of patches during non-duty hours. Specific day to be

determined by unit IAM.

Receive IAVA identifying required patch.

Select required patches from the applicable Web site.

Ensure individual responsible for IAVM has administrative rights to the assets to be

scanned and patched.

Scan assets (servers, routers, switches, and workstations) to identify assets that require

patch application.

Identify ―test‖ machine, apply patch, and scan the machine to confirm patch application.

Apply patch to the remainder of assets.

Issue Conformance Report (via patch application software).

Rescan to validate patch application.

19 November 2008

FM 6-02.71

F-21

FOR OFFICIAL USE ONLY

Appendix G

Brigade Combat Team and Division Deployment Scenarios

During normal peacetime operations, the Army prepares its units for force projection

missions. This requires organizing, training, equipping, and leading Army units to

prepare them for force projection. Readiness and collective deployment training with

Navy and US Air Force controlled lift assets is key in the force projection

preparation.

PREDEPLOYMENT PHASE

G-1. During the predeployment phase, network planners must understand and plan for the complexity of

joint, combined, and tactical network deployment and management needed to support the mission. They

must have a clear understanding of the density of command post subscribers and automation networks in

order to ensure that plans adequately meet requirements and facilitate proper network management. This

requires adequate planning, engineering and support of the requisite nodes, transport links, STEP or teleport

interfaces, network management centers, command and control relationships, and data management

structures needed to support the theater network.

BRIGADE COMBAT TEAM AND DIVISION DEPLOYMENT

EXCURSIONS

G-2. This section outlines the three base scenarios that support the Army providing forces to a CCDR: the

BCT deploying alone, the BCT working directly for a joint headquarters, and several BCTs commanded

and controlled by a division. There may be several branches or sequels to this deployment strategy, but the

network has been designed to support these base capabilities required in the Army Comprehensive Guide to

Modularity volume I version 1.0 (October 2004).

BRIGADE COMBAT TEAM WORKING FOR A FIXED JOINT HEADQUARTERS (EARLY ENTRY)

G-3. Once the Army is notified that a CCDR needs ARFOR, the initial fighting combat capability arrives

in the form of the BCT. This BCT is a multicapable combat formation consisting of organic artillery,

engineer, network, military intelligence, maneuver forces (Armor, mechanized infantry, or light infantry),

and sustainment assets. These capabilities, combined with a multicapable brigade staff, enable the BCT to

work directly for a joint headquarters if necessary.

G-4. An early entry BCT may be task organized under an Army-based command, such as a numbered

Army acting as a JTF or JFLCC. Alternatively, a BCT may be task organized directly under a non-Army

command, such as the geographical combatant command. In either case, the numbered Army provides

supporting services that may be utilized by the BCT. Some of the supporting services include network

service center regional termination, server sanctuary support, and theater support services. For example, as

the BCT prepares for mobilization, the brigade S-6 prepositions a domain server, e-mail server, and VOIP

call manager at the network service center regional. As BCT assets execute the reception, staging, onward

movement, and integration and initial entry phases, they access these services via TDMA and FDMA links

to the network service center regional. The BCT can also access tactical support services via the network

service center regional; e.g., the numbered Army trouble ticketing system, storage services, and Web portal.

G-5. When the BCT deploys, the BCT S-6 coordinates with the CCDR higher headquarters J-6 and the

local SC(T). The SC(T) is the primary network provider for theater LWN. It is also responsible for manning

19 November 2008

FM 6-02.71

G-1

FOR OFFICIAL USE ONLY

Appendix G

and operating command and control of the Service TNOSC. The Service TNOSC performs the NETOPS

functions for the Army theater assets, including the NETOPS interface with Army tactical communications

formations. When the BCT falls directly under a non-Army command, the numbered Army SC(T) may also

provide a liaison team to the BCT or joint command in order to facilitate operational communications. For

example, if a BCT were to fall under the geographical combatant command, the TNCC may not have the

necessary equipment to exchange data with the BCT. In this situation, the numbered Army may employ a

liaison team to support the BCT. This team would provide any necessary data translation to the TNCC and

ensure that the BCT receive the supporting and management services to which it is accustomed.

G-6. The BCT NOSC, as an integral part of the BCT signal company, will take all NETOPS directives

from its higher headquarters’ NOSC with the coordination and assistance from the BCT S-6. As the

ARFOR, it also receives technical direction from the Service TNOSC. Additionally, the tactical formation

will tie into the brigade on the Ku-band’s TDMA using the strategic numbered Army brigade’s UHN. The

BCT signal company may also use existing Ground Mobile Forces or Secure Mobile Anti-Jam Reliable

Tactical Terminals to tie into DISAs STEP sites or teleports. These fixed sites provide the SIPRNET,

NIPRNET, video teleconferencing, and voice connectivity across the DISN. Figure G-1 shows the

connectivity on a single BCT excursion.

X-Band Satellite

STEP/Teleport

KuBand Satellite

UHF-Band Satellite

Terrestrial

Circuits

Hub

2.4 M ku

Terminal

Battalion CP

Terminal

Battalion CP

2.4 M ku

Terminal

TRC-85/93

SMART-T

JNN

BCT Command Post

2.4 M ku

Terminal

Battalion CP

TDMA - IP

FDMA - IP + CKT

UHF via SMART -T

2.4 M ku

Battalion CP

X-Band via GMF

Terminal

LOS

Other Comms available:

UHF SATCOM,

L-Band (BFT & INMARSAT),

SINCGARS, IRIDIUM, MBITR, GBS,

CSS, Trojan Spirit, and HF

Figure G-1. The single BCT excursion

BRIGADE COMBAT TEAM DEPLOYING, WORKING DIRECTLY FOR A DEPLOYED JOINT

HEADQUARTERS

G-7. The Army may be called upon to deploy the BCT in direct support of a deployed JTF, JFLCC, or

other joint headquarters. This scenario requires that the BCT utilize the same communications procedures

G-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Brigade Combat Team and Division Deployment Scenarios

used when deployed alone to connect to the GIG. The additional requirement for direct linkage to the joint

headquarters may require an additional communications link. This link (non-Ku-band TDMA) can be

accomplished with the organic Ku-band FDMA capability or organic Secure Mobile Anti-Jam Reliable

Tactical Terminals. The e-mail or organizational messaging server

(e.g., Defense Message System

Groupware Server) will have to be commissioned into the DISA Defense Message System architecture if a

corps, division, or numbered Army’s Tactical Message System is not present. A redundant capability to the

joint headquarters uses the GIG. Figure G-2 depicts BCT deployment connectivity.

STEP/Teleport

Hub

Ku-Band Satellite

Ft. Belvoir

TS/SCI

SHF X-Band Satellite

LEASE

CIRCUIT

or DISN

INMARSAT

JTF

L-Band Satellite

L -Band Hub

in Sanctuary

EHF-Band Satellite

ISDN

LINES

Vendor

BCT

JNN

L-Band Hub

SMART-T

Trojan Spirit

TSC- 93

JNN

USMC

MAIN

SMART-T

^II Ku

Small

Node

TDMA Mesh #1

TDMA - IP

TD MA - IP

FD MA - IP + CKT

EHF via SMA RT-T

X-Band via GMF

L-Band

C/KU TS Lite

Figure G-2. BCT deployment connectivity

Division Deploying

G-8. The division headquarters may deploy with command and control of several brigade subordinates and

possibly other Service land forces. If the division is given command and control of other Service land

components, joint manning and network management equipment may be necessary. An example of network

management equipment is the joint network management system which is not doctrinally allocated to

division level forces.

G-9. In order to increase responsiveness of a complex network and to facilitate the bandwidth required to

support the division and BCT networks, the division employs a NETOPS cell with the UHN. While the

embedded NETOPS cell provides the management to enable the division network, the UHN flattens the

disparate TDMA satellite network structure, and increases the bandwidth capability from approximately 6

Mbps to 40 Mbps.

19 November 2008

FM 6-02.71

G-3

FOR OFFICIAL USE ONLY

Appendix G

G-10. In addition to expanding bandwidth, the division has the capability to dynamically reassign the

bandwidth so that the communications support plan corresponds with the division commander’s ground

tactical plan. The division weighs one BCT as the main effort for an assault. As the main effort, the division

commander gives the BCT a direct unmanned aerial vehicle or sensor feed that needs to be broadcasted

across the network. The division G-6 can match the communications support plan to enable the added, non-

organic capability. This process is achieved by allocating a larger slice of the division enabled 40 Mbps of

bandwidth when the capability is required. The division hub provides an unprecedented capability that

quickly ―squirts‖ capabilities to those who need it in order to enable the ground tactical plan.

G-11. The division may also use the network service center regional in lieu of or in addition to the division

UHN network service center deployed. The network service center regional provides a persistent hub and

NETOPS capability in support of the division when the network service center deployed, is unavailable,

oversubscribed, or malfunctioning.

G-12. The NETOPS cell, ICW the network hub, links capabilities to network governance or management.

The NETOPS cell performs management as an extension of the GIG’s strategic management, yet the

tactical cell responds to priorities of the division tactical plan. Figure G-3 depicts the division deployed.

Figure G-3. Division deployed

G-4

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Appendix H

Numbered Army Operational Scenarios

In order to illustrate the various roles and responsibilities of the numbered Army in

an operational environment, it is necessary to analyze the likely scenarios in which

the numbered Army would play a critical role. These scenarios drive the discussion

behind the command and control relationships of the different commands across the

phases of operation, as well as the functions performed by the various NETOPS

personnel. Before we can review the detailed NETOPS functions associated by

phase, it is necessary to describe the NETOPS scenario along with the corresponding

command and control relationships.

OVERVIEW

H-1. The following sections will illustrate three common operational scenarios. The first scenario is

comprised of two BCTs that fall under the command of a numbered Army-based JTF. The second scenario

involves a major combat operation in which the numbered Army acts as the JFLCC and commands several

division units. The final scenario depicts a major combat operation scenario in which a numbered Army-

based JTF has been designated as the JTF for the joint operational area. The supporting and

commercialization services are provided by the numbered Army as the ASCC. As a joint operation

progresses, it will pass through one or more of these scenarios in a sequential fashion.

SCENARIO 1: EARLY ENTRY OPERATIONS

H-2. In this scenario, the US Northern Command CCDR has received direction from the CJCS to rotate

units into a theater of operation to relieve an existing Army force. Based on the time phased force

deployment data, US Northern Command directs their numbered Army (FORSCOM) to provide forces

which results in the selection by the Northern Command numbered Army of two BCTs. This force will

serve under a numbered Army-based JTF in the gaining theater.

H-3. Once the BCTs are notified of the deployment order, the BCT staff begins deployment planning

through the combined processes defined in the joint planning process (JP 5.0 Series) and the Army’s

military decision making process. The joint planning process may include any combination of commands

based on the mission. At a minimum, the BCT S-6 will need to conduct joint planning with the JTF J-6,

Service TNOSC in theater, and potentially CONUS based entities that influence the BCT mission under the

JTF.

H-4. The numbered Army, within the operational theater, may execute its role of JTF in several different

formations. The numbered Army may be ―dual-hatted‖ as the JTF and simply assume the responsibilities of

the JTF in addition to its habitual ASCC responsibilities. Alternatively, the numbered Army may designate

a portion of its assets to act as the JTF and these assets may or may not be required to deploy forward into

the operational environment. For the purposes of this scenario, we will assume that the numbered Army has

sufficient connectivity into the tactical environment to enable it to perform its mission from a location

within the fixed-station. JTF J-6 functions are performed by a designated portion of the SC(T). JTF NOSC

functions are performed by the TNT within the TNOSC. The SC(T) and TNT perform all JTF and ARFOR

functions, in addition to all NETOPS functions that would typically be performed by a division when one is

present. This allows the BCTs to function in a fully modular and standardized manner.

19 November 2008

FM 6-02.71

H-1

FOR OFFICIAL USE ONLY

Appendix H

SCENARIO 2: MAJOR COMBAT OPERATIONS

H-5. If the combat operation described above escalates and requires the deployment of additional Army

forces, one or more divisions and additional BCTs and support brigades will be mobilized. In the event of a

small operation of this type, the geographical combatant command may designate a corps or division to act

as the ARFOR. The corps or division acting as an ARFOR is detailed in Appendix D. For the purposes of

this scenario, we will assume that the geographical combatant command chooses to assume direct control of

the operation, and delegate’s control of land forces to the local numbered Army. The numbered Army is

then ―dual-hatted‖ as the JFLCC.

H-6. As the size of the operation grows, additional assets will be required at the SC(T) and TNT to

command and control the operational area. These assets can be drawn from the numbered Army

organizations in other theaters. For example, when a corps or division deploys from CONUS, a portion of

the CONUS TNOSC TNT may also be required to deploy in support of the gaining TNT.

H-7. When the numbered Army is designated to form the basis of a JFLCC, the SC(T) is required to

provide user services and integrate deployed, unit-owned services in support of the JFLCC AOR. For

example, the SC(T) would provide central video teleconferencing hub services, inter-unit VOIP routing

services, domain synchronization, and central storage services. The SC(T) generally delegates this mission

to the SB(T). The signal brigade (theater) may perform these functions from either the network service

center regional or the signal brigade (theater) systems control. The signal brigade (theater) may require

augmentation from signal brigade (theater)s in other theaters in order to provide common user services for

the JFLCC AOR, in addition to the habitual signal brigade (theater) responsibility of providing basic user

services for ITSB/ESB-supported assets.

H-8. The gaining SC(T) provides various supporting services to the corps or division as it enters the

theater. This is a responsibility of the SC(T) regardless of whether the numbered Army has been designated

to act as a member of the operational chain of command. The SC(T) allocates satellite and DISN services

for corps or division use and provides a sanctuary environment at the network service center regional for

corps or division NETOPS services. The local TIC within the TNOSC ensures that the corps or division

network management systems are synchronized with higher headquarters management systems. These

systems include trouble ticketing systems, IA event correlation systems, and network monitoring systems.

To perform these missions, the TIC will typically form a liaison team to augment the corps or division

NETOPS personnel within the UHN or network service center regional.

H-9. The numbered Army, as the JFLCC, may be required to deploy the numbered Army command post to

command and control the joint operational area. This command post is provided with basic network

services via ITSB/ESB signal assets. The command post will also require support from the TNT to provide

SA and to interface with the JFLCC command and staff. The bulk of JFLCC NOSC functions should be

performed from the service TNOSC whenever possible in order to reduce operational environment

transmission requirements and simplify service architecture.

H-10. In a major combat operation, regardless of the operational role of the numbered Army, the SC(T) will

be required to deploy ITSB/ESB assets to support operational environment organizations that may not have

organic signal support. This includes numbered Army-based command posts, certain support brigades, ports

of debarkation, coalition forces, and non-military agencies. ITSB/ESBs that are supporting corps or division

assets, such as a support brigade that is under the OPCON of the corps or division, fall under the command

and control of the corps or division G-6. ITSB/ESBs that support numbered Army or JFLCC assets fall

under the command and control of the signal brigade (theater).

H-11. In major combat operations, a corps or division may become an intermediate tactical headquarters

under the command of the JFLCC. Complexity, span of command, or multinational considerations may

require the use of a third controlling echelon above the brigades. When this occurs, the corps or division G-

6 may require additional augmentation from numbered Army signal brigade (theater) or TNT assets to

perform its mission. As the major combat operation transitions to protracted stability operations, the

additional corps or division headquarters returns to its home station and the normal two-echelon

arrangement will remain.

H-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Numbered Army Operational Scenarios

SCENARIO 3: PROTRACTED STABILITY OPERATIONS SCENARIO

H-12. As a major combat operation transitions to protracted stability operations, the geographical

combatant command may require the numbered Army to form the basis of a JTF to control the joint

operational area. For this scenario, we will assume that the numbered Army will no longer act as a ―dual-

hatted‖ command, but will establish a separate command to control the joint operational area.

H-13. When the numbered Army-based joint operational command is separated from the numbered Army

ASCC, command and management authorities are divided accordingly. The portion of the SC(T) which is

performing ASCC functions acts solely in a support role, while the portion of the SC(T) which augments the

joint command has OPCON of the network operational environment. For example, the deployment support

division within the TNOSC assumes the responsibilities of providing NOSC functions to the joint

command. It is likely that the deployment support division will require pooled assets from other theaters to

perform this function in a major combat operation. The remainder of the TNOSC performs a purely ASCC

function by providing value added and title-10 functions in support of the joint command.

H-14. ITSB/ESB assets which support elements of the joint operational command fall under the command

and control of the joint command. In a large major combat operation scenario, the numbered Army signal

brigade (theater) may be dedicated to the support of the joint command in order to provide a span of

command for the ITSB/ESB units within a joint operational area.

19 November 2008

FM 6-02.71

H-3

FOR OFFICIAL USE ONLY

Appendix I

Fixed Regional Hub Node Operations and Control Plan

The Joint Network Node-Network (JNN-N) hub nodes are critical elements of the

new JNN-N family of equipment that supports commercial Ku-band SATCOM. In

the future, the JNN-N network will also operate off of the Wideband Gapfiller

Satellite constellation. This appendix identifies the roles and responsibilities of the

fixed regional hub node (FRHN), the mobile regional hub node (MRHN), the tactical

hub node (THN), the Training Hub Node and describes the services provided via

these nodes. This appendix will concentrate on the FRHN and the MRHN, and

provide a foundation for the interface to APCs and the migration to the network

service center-regional concept. In addition, this appendix will discuss the FRHN

Operations and Control Plan. The FRHN Operations and Control Plan outlines the

procedures for JNN-N enabled/compatible units to request services from the FRHN.

This manual does not specifically address support for other services, e.g., Army-

Marine Corps Memorandum of Agreement, nor does it specifically address the

CCDR’s use of FRHNs. Rather, it is focused on the roles and responsibilities within

the processes and procedures necessary for the Army to effectively support the

CCDR. It is envisioned that the processes and procedures outlined in this document

can be adjusted to support Joint missions once memorandum of agreements are

established with the other services interested in utilizing the FRHN.

FIXED REGIONAL HUB NODE

JOINT NETWORK NODE-NETWORK HUB NODE’S ROLE IN THE

OBJECTIVE TACTICAL ARCHITECTURE

I-1. The JNN-N architecture is one of several emerging and interdependent initiatives to move towards

the objective tactical Army network architecture (refer to FMI 6-02.60). The JNN-N hub node also plays a

key role in the TRADOC Program Integration Office’s network service center-regional and the CIO/G-6

APC constructs. These related initiatives will not be addressed in any detail within this manual. However,

they are described briefly in order to ensure that the JNN-N hub nodes responsibilities and functions within

the near term and objective environments are clearly understood.

NETWORK SERVICE CENTER-REGIONAL

I-2. The network service center-regional concept addresses the Soldier requirement for ubiquitous,

standardized, and modular service support across the globe. The network service center-regional is a

collection of standardized capabilities which will be physically realized via several disparate facilities and

organizations. While initial network service center-regional capabilities will be Army-focused, the objective

network service center-regional is a joint capability, and would provide standard services to any tactical unit

as defined by joint guidance.

19 November 2008

FM 6-02.71

I-1

FOR OFFICIAL USE ONLY

Appendix I

AREA PROCESSING CENTER

I-3. Under the APC construct, tactical, area, regional, and enterprise services are delivered from a

centralized location in a standardized manner above the post/camp/station, i.e. installation, level. An APC

will be a concentration point for installation interconnectivity, and a location for common services. This

concept will provide a standardized approach to facilitate LWN intranetwork communications and provide

a service delivery paradigm by mission or functional community instead of geographic boundaries. For

example, it will be feasible for Solders to position battle command applications at the APC for primary or

backup services in support of their deployed forces.

JNN-N HUB NODE INTEGRATION WITH THE NETWORK SERVICE CENTER-REGIONAL AND

AREA PROCESSING CENTER

I-4. The APC and JNN-N hub node are two of several physical entities that will ultimately contribute to

the combined network service center-regional capability. In theaters where an APC is not yet present or

fully functional, services may be staged within the FRHN. As the APCs are built, tactical area services will

be migrated to the APC. The APCs will be sized to accommodate additional services and provide data

replication capabilities to facilitate garrison-to-tactical deployment transitions.

TNOSC INTEGRATION WITH THE NETWORK SERVICE CENTER-REGIONAL

I-5. While the FRHN provides the transport and the APC provides data center services, the TNOSC will

provide the NETOPS for the network service center-regional and APC. The TNOSC NETOPS capability

will ensure transport and data center resources are available, reliable, and secure to meet the Solder’s

operational requirements. The TNOSC will be responsible for integrating with other Army and joint

network operations centers (NOCs) and NOSCs, both vertically and horizontally, to gather and report

NETOPS and SA data. The TNOSCs will report vertically to the A-GNOSC, which has Army Enterprise

Management oversight.

JOINT NETWORK NODE-NETWORK HUB NODE’S ROLE IN

WARFIGTER INFORMATION NETWORK-TACTICAL MIGRATION

STRATEGY

I-6. The JNN-N hub node concept plays a critical role in the Army’s migration to the Warfighter

Information Network-Tactical network. As a centralized operational base (strategic) support node to tactical

assets, the JNN-N hub node facilitates the projected migration to a network architecture with ubiquitous low

latency access to operational base (strategic) services and begins the transformation from the current

―federation of networks‖ to an integrated network service provisioning and management paradigm. The

Army CIO/G-6 has developed a comprehensive plan to synchronize JNN to Warfighter Information

Network-Tactical acquisition through fielding implementations.

JOINT NETWORK NODE-NETWORK HUB NODE TYPES

I-7. The paragraphs below discuss the four types of JNN-N hub nodes: FRHN, MRHN, THN, and the

Training Hub Node.

FIXED REGIONAL HUB NODE

I-8. Five FRHNs will be deployed at fixed operational base (strategic) locations in order to provide near

worldwide coverage. FRHNs will allow satellite, voice, and data services to be provisioned and pre-

positioned to support deploying forces as they flow into a theater of operation. FRHNs will be located in the

European, Southwest Asia, and Pacific OCONUS theaters, as well as the CONUS East and West Coasts.

The first FRHN is expected to be operational in Southwest Asia in fiscal year 08. The FRHN is the largest

of the four JNN-N hub node types, and has the following capabilities:

I-2

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Fixed Regional Hub Node Operations and Control Plan

Provides primary hub node connectivity FDMA and TDMA and services for tactical users during

reception, staging, onward movement, and integration operations.

Provides TDMA management support enabling intra-theater brigade-to-brigade level routing and

network services.

Provides COOP for MRHNs and THNs.

Provides primary hub node connectivity and services to expeditionary units (e.g., BCT) not

deploying with a THN.

Provides support to ESBs/ITSBs that are task organized to support all echelons.

Provides a server sanctuary supporting the delivery of theater level services and a stable location

for division or brigade units to host services for their tactical users.

Provides JNN-N hub node connectivity and services for mounted battle command on the move

users.

Supports up to three JNN-N-equipped divisions, or is reconfigurable to support two JNN-N

equipped divisions, four BCTs, and one separate (non-BCT) mission.

Extends DISN voice, data, and video services to the Solders.

Provides assured, low latency connection and reach to the TNCCs for Top Secret/Sensitive

Compartmented Information (TS/SCI) users using JNNs or CPNs as their transport connection to

the FRHN.

Note. For the purpose of this manual, ESBs ITSB are synonymous. An approved doctrinal

naming convention is pending.

I-9. The FRHN can be divided logically into three subcomponents: SATCOM, baseband services, and

NETOPS and user services. Each FRHN is co-located with a DOD Gateway, which enables cost savings by

sharing common infrastructure (e.g., power, heating, ventilation, and air conditioning) and access to the

DISN infrastructure. The DISA Earth Terminal (part of the DOD Gateway) facility houses all FRHN

devices that require physical proximity to satellite and baseband equipment, and will be operated and

maintained on a 24 hours a day, seven days a week basis. Initially, the operations and maintenance

personnel for the FRHN will be contractors (approximately 17 personnel), which is an interim capability

until such time as a BOIP is approved and applied towards Table of Organization and Equipment/Modified

Table of Organization and Equipment. Co-location with a DOD Gateway enables the extension of DISA

services to warfighting units and high bandwidth connectivity into the GIG.

I-10. For FRHN operations, the program manager for Defense Communications and Army Transmission

Systems (DCATS) will install three large, high-bandwidth, multi-carrier satellite terminals. These satellite

terminals will be operated and maintained by the FRHN SATCOM personnel as identified in the FRHN

BOIP. Based on commercial satellite licensing requirements, civilian contractors holding commercial

licenses will be utilized to operate and maintain the commercial satellite subsystems of the FRHN. The

commercial contractors will coordinate any OCONUS host nation approvals/foreign government licensing

requirements and CONUS Federal Communications Commission licensing requirements that are required to

operate the terminals. The NETOPS management and user services will be hosted on the same installation

as the FRHN, and initially will be supported by FRHN NETOPS personnel as identified in the BOIP.

MOBILE REGIONAL HUB NODE

I-11. The MRHN is a transportable hub terminal that operates from a sanctuary location. The MRHN is

intended to:

Provide coverage in areas where an FRHN has not been built or has no coverage.

Provide hub node connectivity to expeditionary units (e.g., BCTs) not deploying with a THN.

Supplement an FRHN when additional capacity or satellite coverage is required.

19 November 2008

FMI 6-02.71

I-3

FOR OFFICIAL USE ONLY

Appendix I

Provide TDMA management support enabling intra-theater brigade-to-brigade level routing and

network services.

Provide a termination capability for mounted battle command on the move terminals.

Provide unit sustainment training and exercise support.

Support autonomous BCTs operating independent of a THN supported division.

Support ESB/ITSB TDMA and FDMA based command posts.

I-12. The theater level tactical MRHN consists of two mobile SATCOM shelters and a mobile baseband

shelter. The MRHNs will be operated and maintained by a theater strategic signal brigade IAW an approved

BOIP. The MRHN is capable of interfacing with DISN points of presence and legacy Army signal systems

(e.g., mobile subscriber equipment, tri-services tactical, and ground mobile forces satellite terminals). There

are currently two first-generation THN terminals which will become the MRHN nodes. These terminals

were originally fielded to the 3ID for Operation Iraqi Freedom 3, and will be transitioned to NETCOM at a

time to be determined. Once 3ID is fielded with the newest generation of THN being built on the family of

medium tactical vehicles, the original two hubs will be assigned to NETCOM to support restoral and

contingency missions. No further acquisition of MRHNs is currently planned. The MRHN manning

structure under NETCOM will be consistent with the approved BOIP. MRHN assets will be pooled and

may be allocated to the various Army theaters as requirements are identified.

TACTICAL HUB NODE

I-13. The THN will be used for direct support to the division and its subordinate units. It provides the

following capabilities:

Primary hub node support to a division and its subordinate units.

TDMA management support enabling intra-theater brigade-to-brigade level routing and network

services.

Service delivery point for division level services and applications.

Termination capability for mounted battle command on the move terminals.

Capability to operate in a sanctuary location w/DISN point of presence access, wherever

possible.

Division level training hub.

I-14. The THN consists of two mobile SATCOM shelters and a mobile baseband shelter. Operations and

maintenance will be IAW the current THN BOIP. The baseband assemblage is capable of interfacing with a

DISN point of presence and legacy (as with the MRHN) Army Signal systems. The current fielding plan is

one THN per Army division.

TRAINING HUB NODE

I-15. The Training Hub Node is currently located at the US Army Signal Center, Ft. Gordon, Georgia. The

Training Hub has capabilities similar to a THN; however, the baseband equipment is located inside a fixed

facility. The Training Hub’s primary purpose is formal school house training to prepare Soldiers to operate,

manage, and interface with JNN-N assets. However, the Training Hub is currently supporting training

readiness exercises, mission rehearsal exercises, etc. until the CONUS FRHNs are fielded and operational.

Once the CONUS FRHNs are fielded, the Training Hub will primarily support school house training and be

available for strategic reserve to support Homeland Defense, Homeland Security, and other CONUS/US

missions. The Training Hub Node will also be used to develop JNN-N hub node doctrine, training, force

structure, and SOPs. The Training Hub Node will transition into a larger Network Service Center-Training

capability in the future when APC and TNOSC capabilities are integrated.

I-4

FM 6-02.71

19 November 2008

FOR OFFICIAL USE ONLY

Military reference books and manuals (2009-2023, Volume 7) - page 33