Atch 6 BNCC AFNetOps Infra IPlan.pdf

Air Force Network Operations (AFNetOps)

Infrastructure Implementation Plan

1 February 2008

DRAFT

FOR OFFICIAL USE ONLY

FA3022-08-Q-0001

Attachment 6 i

DISCLAIMER

THE USE OF THE NAME OR MARK OF ANY SPECIFIC MANUFACTURER,

COMMERCIAL PRODUCT, COMMODITY, OR SERVICE IN THIS PUBLICATION DOES

NOT IMPLY ENDORSEMENT BY THE AIR FORCE.

AFNETOPS I-PLAN 1 FEBRUARY 2008

ii

APPROVALS

Name: DOUGLAS W. GRAY, YC-D, DAF Date Title: Director, Architectures and Analysis

Name: STEVEN J. HENNESSY, Colonel, USAF Date Title: Director, Enterprise Capabilities

Name: CARL WILLIAMSON, Colonel, USAF Date Title: Commander, HQ Air Force Communications Agency

AFNETOPS I-PLAN 1 FEBRUARY 2008

iii

TABLE OF CONTENTS

1 PURPOSE

2 OBJECTIVES

3 AFNETOPS MISSION CAPABILITIES

4 SCOPE

5 AFNETOPS IOC & FOC DEFINITIONS

5.1 AFNetOps IOC

5.2 AFNetOps FOC

6 MIGRATION PLAN

6.1 MAJCOM AFNetOps Migration Plans

6.2 AFNetOps Implementation Battle Rhythm

6.3 AFNetOps Fielding Strategy FY08 through FY11

6.4 Active Directory Migration to a Single AF Forest

6.5 Area Processing Center Implementation

6.6 APC Capabilities Testing

6.7 APC Bandwidth Analysis

6.8 CITS Production APCs

6.9 Baseline ESU Management

6.10 CITS Turnkey ESU Solution

6.11 Virtualization Initiatives During AFNetOps Implementation

6.12 I-NOSC Migration Summary

6.13 Enterprise Service Desk Initiative

6.14 Service Oriented Architecture Initial Infrastructure Build

6.15 Functional Mission Application Migration Plan

6.16 Cross Domain Solutions Migration Plan

7 ROLES AND RESPONSIBILITIES

8 RISK MANAGEMENT

9 MANPOWER

10 AFNETOPS BATTLE RHYTHM PROJECT PLAN

11 GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION

11.1 References

11.2 Abbreviations and Acronyms

ATTACHMENT 1 - UNITED STATES AIR FORCE NETWORK OPERATIONS

FUNCTIONAL CONCEPT ............................................................ATTACHMENT 1-1

ATTACHMENT 2 - MEMORANDUM OF AGREEMENT...................ATTACHMENT 2-1

TABLE OF FIGURES

FIGURE １ — AFNETOPS IOC/FOC

FIGURE ２— AFNETOPS IMPLEMENTATION BATTLE RHYTHM, AS OF JAN 2008

AFNETOPS Implementation Plan

EXECUTIVE SUMMARY 1

The initial thrust of Air Force Network Operations (AFNetOps) infrastructure implementation 2 focuses on immediate foundational initiatives for singularly managed command and control of 3 Air Force Enterprise Networks (AFEN). All implementation plans and accompanying solutions 4 described in this plan are based on requirements stated in the 12 October 2006 AFNetOps 5 Functional Concept (Attachment 1), and direction from the AFNetOps Transformation Office 6 (SAF/XCT), functional leads in Air Combat Command Network Systems (ACC/A6N), 38 7 Engineering Installation Group (EIG), and the dedicated team from the AFNetOps community 8 focused on achieving the goals of the AFNetOps vision. 9 High-level timelines for AFNetOps capability delivery are contained in the core document. 11 Phasing of AFNetOps capabilities was carefully prioritized based on mission requirements for 12 increased security posture through a singularly managed infrastructure, while at the same time 13 targeting operational and investment efficiencies to alleviate impacts sustained by Congressional 14 Program Budget Decision 720 manpower cuts and funding losses. 15 This AFNetOps Infrastructure Implementation Plan (I-Plan) core document summarizes the 17 major implementation activities and overall execution plan for fiscal year 2008 (FY08) through 18 FY11. Accompanying appendices for Area Processing Center, Integrated Network Operations 19 and Security Center, Enterprise Services Unit, and Enterprise IT Service Desk contain detailed 20 implementation steps required for the respective mission area. Implementation details contained 21 in the appendices represent works in progress and will be updated on a semiannual basis or more 22 frequently as the implementation progresses. Updates to the core document will be considered 23 on an annual basis. The AFNetOps General Officer Steering Group (GOSG) and accompanying 24 sub-working groups will ensure these plans and their execution in Air Force networks reach the 25 level of integration and fidelity necessary for successful AFNetOps transformation. 26 The I-Plan is under the control of the AFNetOps GOSG; the appendices are controlled by the 28 AFNetOps GOSG Action Group. More information on the AFNetOps GOSG and their charter 29 can be found on the AFNetOps GOSG Community of Practice Web site at 30 (https://afkm.wpafb.af.mil/ASPs/docman/DOCMain.asp?Tab=0&FolderID=OO-SC-AF-44-31 2&Filter=OO-SC-AF-44). 32

INTRODUCTION 1

In July 2003, the Air Force Chief of Staff announced the establishment of Air Force Network 3 Operations (AFNetOps) to ensure network control and defensive measures are applied in a 4 coherent, disciplined fashion under a single Air Force commander. The direction was to provide 5 the same command and control (C2) discipline to Air Force networks that are applied to weapon 6 systems. To achieve this vision, the Air Force has been restructuring the way it creates and 7 sustains network systems. 8

“The Department of Defense (DoD) is transforming the way it conducts 10 warfare, business operations, and enterprise management. As part of this 11 transformation, the Department has embraced the concept of “Net-Centricity.” 12 Net-Centricity is the realization of a robust, globally interconnected, network 13 environment (including infrastructure, systems, processes, and people) in 14 which data is shared in a timely and seamless way among users, applications, 15 and platforms, during all phases of warfighting efforts. By securely 16 interconnecting people and systems, independent of time or location Net-17 Centricity enables substantially improved situational awareness and 18 significantly shortened decision-making cycles. Users are empowered to better 19 protect assets, more effectively exploit information, more efficiently use 20 resources, and unify the forces by supporting extended, collaborative 21 communities to focus on the mission.” [Net-Centric Enterprise Services 22 Capability Development Document Version 0.9.2, 28 November 2005 23 (http://www.disa.mil/nces/acquisition_resources.html)]. 24

This vision depends on information sharing among Air Force users and DoD users, alike. Users 26 depend on the services and availability of the DoD Global Information Grid (GIG) — provided 27 in a timely manner. The AFEN will provide services helping users find, access, collaborate, 28 fuse, display, manage, and store information. To meet this vision, the Air Force must change the 29 way it operates in the Air Force portion of the GIG. The AFNetOps Functional Concept 30 (Attachment 1) defines the global-level C2 for Air Force networks as “AFNetOps.” AFNetOps 31 must transform the AFEN from a loose federation of Major Command (MAJCOM)-centered 32 components to an enterprise-centric network. Day-to-day C2 of the network must be exercised 33 by a single commander. 34 The overarching goals of AFNetOps Transformation and this AFNetOps I-Plan are to establish 36 the communications infrastructure for a centralized C2 capability and to minimize the resources 37 needed through consolidation of the MAJCOM Network Operations Security Centers (NOSCs) 38 into two regional Integrated Network Operations and Security Centers (I-NOSCs) that manage 39 and administer information technology (IT) and the AFEN. Core IT services (e.g., electronic 40 mail (E-mail), storage, directory services) located at base Network Control Centers (NCCs) will 41 be regionally consolidated into Area Processing Centers (APCs). Initially, MAJCOM-specific 42 applications hosted and administered at MAJCOM NOSCs will physically remain in MAJCOM 43 communications control centers (MCCCs) under the administration of MCCC personnel. At 44 transformation end-state, MAJCOM-specific applications will have transferred to AFNetOps 45 control as part of an APC under the auspices of a Services-Oriented Architecture (SOA) 46 environment. APCs will be administered by Enterprise Services Units (ESUs) collocated with 1 the two I-NOSCs. Two outside the continental United States (OCONUS) ESUs, detachments of 2 I-NOSC East (I-NOSC-E at Langley AFB) and I-NOSC West (I-NOSC-W at Peterson AFB), are 3 located in Europe and Pacific. The Air Force Enterprise IT Service Desk (ESD), formerly called 4 Consolidated Help Desk (CHD), will serve as the central point for troubleshooting and providing 5 customer service solutions. NCCs will transition to "lights dim" operations and provide on-site 6 support to the ESD, when needed. 7

1 PURPOSE 8

This I-Plan lays out the integrated, actionable plan to synchronize Air Force activities leading to 9 the establishment of an enterprise AFNetOps capability. For program timelines and 10 interdependencies for AFNetOps infrastructure implementation, reference the Air Force-level 11 Integrated Master Schedule (IMS) on the SAF/SC Integrated Master Scheduling Community of 12 Practice (CoP) Web site at (https://afkm.wpafb.af.mil/ASPs/CoP/EntryCoP.asp?Filter=OO-TR-AF-56). 13

2 OBJECTIVES 14

The objective of this I-Plan is to transform IT services and capabilities through the establishment 15 of AFNetOps within Air Force Cyberspace Command (AFCYBER). The transformation will 16

• Integrate C2 for operations and defense of the network under a single chain of 18 command 19

• Consolidate and centralize IT assets, where appropriate 20

• Shape the force in response to Program Budget Decision (PBD) 720 making 21 necessary adjustments via permanent change of stations or contract support 22

• Insert technology and recapitalize equipment to maximize our investment in Air 23

Force existing infrastructure 24

• Transition from MAJCOM-Centric to Net-Centric operations 25

• Improve management (also known as NetOps) and IT delivery 26

• Improve Information Security and Information Assurance 27

• Improve Computer Network Defense posture 28

• Reduce Total Cost of Ownership 29

For the Air Force to meet these objectives, organizational functions must be systematically 31 integrated, as technology and funding allow. The AFEN includes Air Force-owned and leased 32 communications, computing systems, and associated services under the C2 of the AFNetOps 33 Commander. Specifically, it includes the end-to-end set of information capabilities; associated 34 processes; and personnel that collect, process, store, disseminate, and manage information 35 necessary to achieve information superiority on demand for the warfighters, policy makers, and 36 support personnel. 37 This transformation effort requires continued development of AFNetOps and AFCYBER 39 concepts. Organizationally this includes the Air Force Network Operations Center (AFNOC) 40 and its oversight of I-NOSC-E, at Langley AFB, and I-NOSC-W, at Peterson AFB, and the 41 extension of their capabilities. 42

3 AFNETOPS MISSION CAPABILITIES 1

The desired effect of AFNetOps is full-spectrum decision superiority, achieved through assured 2 system and network availability, assured information protection, and assured information 3 delivery. This includes providing the warfighter with robust network warfare capabilities based 4 on seamless and secure network connectivity and information systems access across terrestrial, 5 airborne, and space networks. 6 More clearly defined C2 and integrated capabilities allow: 8

• Continuous situational awareness of Air Force networks, as well as potential and 10 ongoing Combat Air Force, Mobility Air Force, and space force operations 11

• On-demand and real-time operational status of networks, core services, and 12 applications directly serving or influencing the warfighter’s area of responsibility, 13 eliminating the need for scheduled manual reporting 14

• Resource allocation (e.g., bandwidth, frequencies) in response to multiple and/or 15 conflicting warfighter requirements 16

• Characterization and response to anomalous activity, including “low and slow” 17 network probe and exploitation efforts, implementing appropriate defensive actions or 18 countermeasures, trend analysis of network incidents (e.g., probes, intrusions, virus 19 outbreaks), outages, and degradation events 20

• Implementation of security countermeasures and/or network restoration priorities 21 after an adverse network event 22

• Proactively adjust AFEN and implement configurations to adjust risk posture and 23 response to credible threat analysis and anomalous threats based on impact to 24 operations 25

4 SCOPE 26

This I-Plan addresses the actions required to bring the AFNetOps concept to Initial Operational 27 Capability (IOC) and subsequently to Full Operational Capability (FOC). The first iteration of 28 this plan will establish FOC at which AFNetOps provides full C2 of terrestrial Non-Secure 29 Internet Protocol Router Network (NIPRNET) and Secret Internet Protocol Router Network 30 (SIPRNET). FOC integrates the Air National Guard and AF Reserve network operations into the 31 overall AFNetOps Transformation effort; ensuring network control and defensive measures are 32 applied in a coherent, disciplined fashion under a single Air Force commander. The integration 33 of airborne and space networks will begin sometime after 2008 and will be addressed in future 34 iterations of this I-Plan, as appropriate.1 35 This plan will leverage and coordinate the various programs and initiatives bringing network 37 operations capabilities into the AFNetOps construct. 38

1 Source: HQ USAF PAD 07-10, 13 November 2007

5 AFNETOPS IOC & FOC DEFINITIONS 1

AFNetOps IOC and FOC are defined in the HQ USAF Program Action Directory (PAD) 07-10, 2 13 November 2007. 3

5.1 AFNetOps IOC 4

AFNetOps IOC is defined as the transfer of 202 authorizations and full implementation of the 5 following capabilities: 6

• Two I-NOSCs assume AFNetOps responsibilities from MAJCOM NOSCs or base 8 level communications units and manage NIPRNET/SIPRNET boundary protection 9 service to all operating locations. 10

• AFNetOps construct is capable of providing effective reporting to Joint Task Force-11 Global Network Operations (JTF-GNO) and managing the implementation of JTF-12 GNO directives through the generation and execution of Network Tasking Orders 13

(NTO). 14

The AFNOC generates an NTO (modeled after the air and space operations 15 center Air Tasking Order development process). 16

I-NOSCs possess the capability to execute the NTO. 17 AFNetOps construct demonstrates the ability to generate and execute NTOs 18 through global exercises such as BULWARK DEFENDER. 19

5.2 AFNetOps FOC 20

AFNetOps FOC is defined as AFNetOps providing full C2 of AFEN and cyberspace operations 21 capabilities. FOC capabilities consist of IOC plus: 22

• AFNetOps provides operating locations: a consolidated network defense, transport, 24 and boundary, plus core services capabilities. 25

• The AFNOC Network Security Division (NSD), Network Operations Division 26 (NOD), I-NOSCs/ESUs, APCs, and ESDs are operationally integrated into the 27 network operations and defense mission of AFCYBER through defined tactics, 28 techniques, and procedures. 29

• Supporting resource transfers, including manpower, are completed with baseline 30 funding secured; all AFNetOps equipment is in place, on line, and fully mission 31 capable. 32

• The AFNOC and 67th Network Warfare Wing are able to mission-qualify AFNetOps 33 crew members and re-evaluate their mission qualifications on a recurring basis. 34

• At FOC for the I-NOSC, the NCC will be “lights dim” and will perform maintenance 35 under I-NOSC C2. 36

Figure １ shows the AFNetOps transfer of the C2, location, and administration of IT services 37 from MAJCOMs to AFNetOps. IT operational control (IT OPCON) and administrative control 38 (ADCON) are depicted. Applications hosted and administered at MAJCOM Network NOSCs 39 and base NCC will be regionally consolidated into APCs. APCs will be administered by four 40 ESUs (2 CONUS/2 OCONUS) aligned under two I-NOSCs. An ESD will serve as central point 41 for troubleshooting and customer service solutions. NCCs will transition to "lights dim" 1 operations and provide on-site support to the ESD, when needed. 2

Figure １ — AFNetOps IOC/FOC 3

NOTE: Acronyms in this figure are defined in Section 11. 5

6 MIGRATION PLAN 6

Initially, the following capabilities will be consolidated to the APC, and management tasks will 7 be performed at the ESU: 8

• Directory Services 10

Active Directory 11 Identification Management 12 Directory Services 13 Authentication 14

Domain Name Service (DNS), Dynamic Host Control Protocol, Windows 1 Internet Naming Service, Internet Protocol (IP) 2

Certification Management 3

• Data storage/Application Hosting 4

Storage Area Network 5 Network Attached Storage 6 Back-Up/Archive 7 Records Management 8

• Web Services 9 Portal Services 10 Database Services 11

• E-mail/Messaging Services 12 Exchange/ Common Access Card (CAC)-enabled Outlook Web Access (OWA) 13 Collaboration Tools 14 Wireless Messaging 15 Defense Messaging Service/Automated Message Handling System 16

The remaining services will be migrated in a tiered approach with the AFNetOps Integration 18 Office (AFCA/ECI) and the Air Force Communications Agency Architectures and Analysis 19 Directorate (AFCA/EA) leading integration of remaining services. As the “production” APCs 20 come online, the migration will be synchronized for all services. These services will be the 21 foundation for the AFNetOps singularly managed infrastructure. The first three APCs to stand 22 up will continue to use existing boundary and information protection solutions. APC #4 through 23 APC #112 will take advantage of installed Combat Information Transport System (CITS) Block 24 30 infrastructure and will be considered standard “production” APCs. MCCCs stay with 25 MAJCOMs which maintain operational responsibility of core services until they are migrated to 26 the APC and under AFNetOps control. 27 At APC end state, all identified mission applications will be migrated as applications in their 29 legacy state or their data to the SOA environment as services. Reference the APC appendix for 30 further details on the application migration plan. 31 Core services to be hosted at the APC at the end state and managed by the ESUs include: 33

• Service Oriented Core Enterprise Services 35 Consolidated Personnel Directory 36 Enterprise Messaging 37 Transaction Management 38 Workflow Management 39

2 As of January 2008, it is estimated that 11 APCs are required based on current user population and requirements, and operational and technical analysis of proposed sites and facilities, geographical consideration, existing and planned infrastructure, environmental factors, and power grid mappings.

Metadata Catalog 1 Metadata Registry 2 Services Registry 3 Semantic Discovery Adaptability 4

• Computing Services 5 Service/Application Hosting 6 Server Virtualization 7 Application Servers 8

• Service Oriented Information Assurance Services 9 Identity Authentication 10 Identity Management 11 Assured Information Sharing and Management 12

• Enterprise Service Management 13 Monitoring for Quality of Service 14 Governance of Configuration 15 Contract Management (to ensure a stable work environment) 16

6.1 MAJCOM AFNetOps Migration Plans 17

AFCA/ECI together with AFCA/EA and respective lead commands will work directly with 18 MAJCOMs to build detailed migration plans for hosting core services at their identified APC 19 locations. Migration to APCs will be MAJCOM centric and in synch with their migration into 20 the Air Force Active Directory user forest. Once fully established, APCs will be optimized to 21 host Air Force users on a regional basis and carefully load balanced for optimization of 22 bandwidth and user service availability. Migration schedules will be focused on operational 23 needs and manpower shortfalls and will be accomplished in a tiered approach with testing of 24 each service in the AFCA Technical Interoperability Facility (TIF) prior to deployment on the 25 AFEN. 38 EIG, with consolidated requirements from AFCA lead commands and MAJCOM 26 requirements, will perform detailed site surveys at each prospective APC location to determine 27 facility requirements. AFNetOps Lead Command, together with AFCA AFNetOps Integration 28 Office, will build detailed service level agreements with MAJCOMs to ensure ESU manpower is 29 in place to manage the services and ensure ESD capability is sufficient to provide help desk 30 services to the new users and core services migrating under AFNetOps control. 31 AFCA lead commands will provide updates to site-specific migration schedules for AFNetOps 33 implementation on a weekly basis as maintained in the IMS at 34 (https://afkm.wpafb.af.mil/ASPs/CoP/EntryCoP.asp?Filter=OO-TR-AF-56). Additionally, lead 35 commands will provide detailed implementation plans for migration of their capabilities to 36 AFNetOps operational nodes, as required by AFNetOps Integration Office, to integrate and 37 synchronize plans for MAJCOMs. AFCA lead commands will perform and publish detailed 38 analysis of alternatives (e.g., operational, technical, and cost considerations) to determine if 39 capabilities will be deployed to APCs in lieu of installing them at 108 base locations. 40

AFCA/EA will be responsible for documentation of the detailed migration plans based on inputs 1 from AFNetOps Integration Office, relative MAJCOM requirements, and consolidation of 2 AFCA lead command plans and schedules. All plans will be synchronized with the AFNetOps 3 battle rhythm and coordinated with AFNetOps lead command (ACC/A6N). The resulting 4 migration plans will be used as input to identify and update critical implementation activities and 5 capabilities deliverables in the AFNetOps portion of the IMS. Additionally, AFCA/EA will 6 update respective areas of the AFNetOps I-Plan appendices with MAJCOM migration plans as 7 required. 8

6.2 AFNetOps Implementation Battle Rhythm 9

Figure 2 displays the notional high level view of the migration timeline to move network 10 operations from the MAJCOMs into AFNetOps. The end state is a fully functioning AFNetOps 11 construct capable of sustaining long-term net-centric operations. The AFNetOps 12 implementation, or Battle Rhythm, lays out the overall infrastructure fielding strategy to provide 13 the foundation to achieve centralized management and control of the AFNet. Prior to standup of 14 each APC, an ESD function will be expanded to begin handling the users migrating from their 15 host base network to an APC. Concurrently, an ESU management function will be enabled to 16 manage the users and core services now hosted at an APC. Due to funding limitations at the 17 time of this schedule release, help desk and management functions will be managed by the 18 MAJCOMs until ESU and ESD capabilities are implemented. Transfer from host 19 base/MAJCOM will occur after careful coordination and detailed service agreements between 20 the ESU and serviced MAJCOM. The user count along the bottom identifies the phased mailbox 21 migration of Air Force users to the AFNet. As initial APCs stand up, Microsoft Exchange and 22 Active Directory will be migrated and consolidated into one integrated Air Force forest, one 23 MAJCOM at a time. Bandwidth analysis will be conducted during user migrations for the first 24 three bases of each MAJCOM as their services are integrated into APCs. The traffic analysis 25 will focus on potential changes in bandwidth utilization and identify requirements for bandwidth 26 upgrades for bases hosted by a particular APC. Migration of base boundary control and 27 management to respective I-NOSCs will also be implemented in a phased approach. 28

Figure ２— AFNetOps Implementation Battle Rhythm, as of Jan 20083 1

NOTE: Acronyms in this figure are defined in Section 11. 3

6.3 AFNetOps Fielding Strategy FY08 through FY11 4

As of this document release, the following capabilities are planned for implementation as 5 presented by the AFNetOps Integration Office lead to the AF/A6 Forum hosted by SAF/XC on 6 18 January 2008: 7

FY08 AFNetOps Fielding Strategy 9

• Begin migration of Base Boundary Control/Management to I-NOSCs 10

• Build out Langley, Peterson, and Hickam ESU 11

• Begin building ESD capability at San Antonio, Ramstein, and Hickam 12

• Finish Scott and Air Force District of Washington (AFDW) APC builds 13

3 For the latest schedule information, reference the AFNetOps portion of the Integrated Master Schedule on the SAF/XC Integrated Master Scheduling CoP at (https://afkm.wpafb.af.mil/ASPs/CoP/EntryCoP.asp?Filter=OO-TR-AF-56).

• Install SOA Initial Infrastructure Build (SOA IIB) at Scott APC 1

• Begin building Wright-Patterson APC 2

FY09 AFNetOps Fielding Strategy 4

• Finish migration of Base Boundary Control/Management to I-NOSCs 5

• Build ESU at Ramstein 6

• Continue expanding ESD at San Antonio, Ramstein, and Hickam 7

• Finish Wright-Patterson APC build 8

• Install SOA IIB at Wright-Patterson APC 9

• Build Hickam and Ramstein APCs 10

• Begin building ESD at Gunter AFB 11

FY10 AFNetOps Fielding Strategy 13

• Finish ESD expansion at all four locations 14

• Build Buckley/Offutt, Yokota, Osan, Molesworth, and Aviano APCs 15

• Install SOA IIB at Ramstein, Hickam, and Buckley/Offutt APCs 16

FY11 AFNetOps Fielding Strategy 18

• Build Gunter APC 19

• Review the Gunter/DISA agreements 20

• May be able to accelerate with new agreement on Defense Enterprise Computing 21

Centers floor space 22

6.4 Active Directory Migration to a Single AF Forest 23

The Air Force is consolidating base-level authentication services to improve security, reduce 24 costs, and enable new capabilities like persistent E-mail and centralized management. Air Force 25 Headquarters, Office of Warfighting Integration and Chief Information Office (SAF/XC), in 26 conjunction with AFCA, is directing a redesign and consolidation of the MAJCOM-centric 27 Active Directory and Exchange (ADX) E-mail architecture. This will enable the AFNetOps 28 Commander to gain full visibility across the entire Air Force infrastructure, reduce the cost and 29 complexity of operating ADX across the Air Force, and provide seamless integration between 30 MAJCOM-based infrastructures to enable enterprise-wide applications. 31 Air Force network consolidation efforts were initiated by AFCA with the E-mail for Life (E4L) 33 program. E4L provides a persistent E-mail address for Air Force active duty, reserves, civilian, 34 and contractor personnel for their entire time of service to the Air Force. Network consolidation 35 efforts are currently underway to establish the foundation for regionalized APCs during ADX 36 consolidation. AFCA will install new equipment to support an Exchange environment in a 37 single Air Force Forest, migrating users and mailboxes into this new construct which will be 38 managed by ESU components assigned to the 67 NWW. The core services to be consolidated by 39 the ADX initiative include: 40

• Mailbox Servers and Services — used to retain user and organizational mailboxes as 1 well as public folder data 2

• Mobile Client Access Servers and Services — used to provide E-mail and calendar 3 access to mobile clients to include Blackberry and WinMobile 4

• Web and Outlook Client Access Servers and Services — used to provide remote 5 access to E-mail across boundary devices to include virtual private Network (VPN) 6 and OWA 7

• Patch Management and Compliance Scanning (also known as Systems Management 8 Server and Internet Security Systems) services — will continue to be provided with 9 no change to the current processes 10

• CAC-enabled VPN services — will be provided in the manner it is today 11

• Hub Transports Servers and Services — used for E-mail routing and message hygiene 12 within the Air Force network 13

• Boundary mail filtering and hygiene servers and services — used for filtering and 14 performing hygiene of E-mail inbound to the Air Force network 15

• Application Layer Firewalls — used to provide packet inspection for external client 16 request for E-mail services. These firewalls are also used to facilitate E-mail routing 17 from client to server across boundary devices 18

6.5 Area Processing Center Implementation 19

Air Mobility Command’s messaging services will be the first to migrate to this new centralized 20 environment at the first APC, located at Scott AFB, followed by the APC at Andrews AFB and 21 the APC at Wright-Patterson AFB using already established facilities and infrastructure. ADX 22 lays the foundation for all APCs. There are 11 APCs planned which will be operated and 23 maintained by the AFNetOps. The AFNetOps Functional Concept defines the APC as regional 24 data centers housing core enterprise services equipment where data processing, information 25 storage, and performance of day-to-day hardware maintenance occur. MAJCOM-specific 26 systems remaining under MAJCOM control will reside in the MCCC until such time that the 27 data can be migrated into the APC SOA environment. APCs will be remotely managed by their 28 respective ESU, thus requiring minimal on-site manning. 29

6.6 APC Capabilities Testing 30

AFCA/ENS is the lead for capabilities testing. Before any service is migrated into an operational 31 network at an APC, it will be tested and evaluated using the TIF to ensure operability and ease of 32 transition using standardized approaches from documented lessons learned. Their scope and 33 responsibilities will be more thoroughly defined as APCs begin to stand up and come online. 34

6.7 APC Bandwidth Analysis 35

AFCA/ENA is performing bandwidth analysis of traffic before and after user migration to the 36 single AF forest to estimate and plan for bandwidth upgrades required as the users traffic now 37 must travel to/from the nearest available APC for their core services. 38

6.8 CITS Production APCs 1

CITS Lead Command, AFCA/ECN, is leading the effort to build production APCs with the first 2 site slated for Fall 2008. CITS implementation will ensure proper sustainment, maintenance, 3 training, and standardization across all Air Force APCs and compatibility with other components 4 of the Air Force Enterprise Network (e.g., CITS Block 30). APCs will have IOC and FOC. The 5 intent of IOC for the APCs is to establish regional computing centers that provide a secure, 6 reliable environment in which legacy applications can execute and be managed by the ESUs. 7 FOC for the APCs will be attained when every APC adopts the infrastructure for a service 8 oriented environment in addition to continued support for legacy mission system applications. 9 Initially, core capabilities such as personnel directory, authentication, and E-mail will be 10 provided from the APCs. As they mature, additional legacy applications will be hosted at the 11 APCs. The end goal is to transition all terrestrial networks under the AFNetOps construct and 12 transition MAJCOM-specific mission systems away from legacy platforms to consolidate them 13 with other services at the APC. Server virtualization and SOA will be used as the underlying 14 paradigms for implementation. 15 The APCs will leverage existing Air Force standard software and hardware when applicable, and 17 a warranty for the hardware can be obtained. The tools are to be used in the APC for remotely 18 monitoring, managing, and configuring current core services along with unique mission system 19 applications at NCCs. Some system hardware will remain at the NCCs to maintain network 20 integrity, but management will still migrate to the ESUs. 21 Production APC design will be based on vetted Air Force requirements for APC boundary 23 requirements, application server requirements, storage, Continuity of Operations (COOP), and 24 delivery of technical orders and training. The APC Systems Requirements Document (SRD) and 25 companion ESU SRD are in draft form at the time of this I-Plan release with estimated 26 MAJCOM coordination release in April 2008. CITS is expected to build the remaining eight 27 APCs and bring the initial APCs (i.e., Scott AFB, AFDW at Andrews AFB, and Wright-28 Patterson AFB) to the standard baseline. 29 Locations planned for APCs are: 31

CONUS 33

• AFDW at Andrews AFB 34

• Buckley AFB or Offutt AFB 35

• Gunter Annex 36

• Scott AFB 37

• Wright-Patterson AFB 38

OCONUS 40

• Aviano AB 41

• Hickam AFB 42

• Osan AB 43

• RAF Molesworth 1

• Ramstein AB 2

• Yokota AB 3

6.9 Baseline ESU Management 4

PACAF/A6, the lead for establishing the baseline for ESU capabilities, is heading an ESU 5 contracting effort to establish the cross-forest trust required for managing base networks 6 remotely using VPNs and for including ADX and other core services and equipment in place 7 until physical consolidation and ADX migration is complete. The intent is to gain administrative 8 access to all Active Directory equipment at bases and transition management responsibilities 9 from base NCCs to ESUs. ESUs are responsible for remote administration of core services 10 located in APCs and bases in their portion of the Air Force provisioned portion of the GIG. 11 ESUs oversee delivery of organizational and individual E-mail to the desktop, shared file/data 12 storage, capability to print to network printers, centrally-managed Web services, standard 13 desktop environment, DNS, IP address space management, Active Directory, Remote Access 14 Services, and Network Time Protocol management. Implementation details are specified in the 15 ESU appendix. 16

6.10 CITS Turnkey ESU Solution 17

CITS Lead Command, AFCA/ECN, is leading the design and implementation of standardized 18 solution for ESUs. The ESU implementation will deploy and utilize systems and tools for 19 centralized monitoring, management, and configuration control of all ESU resources. ESUs 20 operate 24 hours a day/7 days a week performing troubleshooting procedures to restore faults 21 and providing help desk services to field units supported by their APCs and I-NOSC. 22 The ESU will centrally manage assets remotely located at APCs and the NCCs that provide 24 current enterprise core services and other unique mission system applications at the same level as 25 if these services were provided locally by base NCCs. It will leverage the existing systems and 26 tools for centralized monitoring, management, and configuration control of NCC and APC 27 resources if the hardware has at least a 5-year warranty or a warranty that can be extended to 5 28 years at a minimum. Some system hardware will remain at the NCCs to maintain network 29 integrity, but management will still migrate to the ESUs. The baseline ESU initiative by PACAF 30 and lessons learned will be leveraged by CITS for the turnkey-ESU solution. 31 ESUs will enable AFNetOps capability to manage all core services and other unique mission 33 system applications resources for the AFNetOps Commander in an out-of-band management 34 network. With the ESUs managing the APCs using standardized toolsets, the AFNetOps 35 community will reap the benefits of standardization, i.e., reduced training and maintenance costs 36 along with increased operational flexibility and capacity. The CITS ESU solution is scheduled 37 to be operational by Fall 2008 to coincide with operation of the CITS production APC, also to be 38 operational by Fall 2008. 39

6.11 Virtualization Initiatives During AFNetOps Implementation 40 While efforts to consolidate ADX and to remotely manage base networks from ESUs are 41 ongoing, virtualization across remaining MCCC applications and servers is recommended to 42 reduce touch maintenance required at bases until those applications can be migrated to the 1 respective APC SOA environment. Additionally, for those bases identified for APCs, 2 virtualization will help free up additional floor space and minimize power and heating, 3 ventilation, and air conditioning requirements. 4

6.12 I-NOSC Migration Summary 5

The I-NOSC is the Air Force’s operational-level warfighting command center for network 6 defense and transport. As the execution arm of the Air Force Network Operations and Security 7 Center (AFNOSC), its role is to operate and defend the Air Force-provisioned portion of the 8 Global Information Grid (GIG) by maintaining the network infrastructure and managing the 9 functions of security hardware, network monitoring and control, and domain name services. 10 Each I-NOSC will provide C2 of base-level Network Control Centers (NCCs) along with remote 11 administration of enterprise-wide infrastructure. The transition of base-level responsibilities to 12 the I-NOSC will be accomplished in phases with the Initial Operating Capability occurring when 13 the I-NOSC takes control of any portion of the Air Force-provisioned portion of the GIG not 14 under the control of the NOD or the NSD. FOC will occur when the I-NOSC has direct C2 of 15 the entire terrestrial portion of the Air Force-provisioned portion of the GIG. 16 The AFNetOps execution of enterprise security will be structured on a three-tier system defined 18 by the JTF-GNO and Office of the Secretary of Defense/Networks and Information Integration 19 (OSD/NII) roadmaps with the AFNOC providing Tier 1enterprise level and the APC providing 20 Tier 3. The I-NOSC will provide Tier 2 responsibilities for network security and core services 21 that are currently performed by the MAJCOM NOSCs. These include: 22

• Monitoring Air Force gateway boundary protection devices 24

• Configuration of network infrastructure components 25

• IP address management 26

• Real-time tracking of network activity to identify anomalous events and respond 27 appropriately 28

• Ensuring the seamless, secure, and reliable delivery of information across Air Force 29 networks by managing: 30

• Organizational and individual E-mail 31

• Shared data storage 32

• Networked printing 33

• Web services and applications 34

For program timelines and interdependencies for I-NOSC implementation, reference the Air 36 Force-level Integrated Master Schedule (IMS) on the SAF/SC Integrated Master Scheduling 37 Community of Practice (CoP) Web site at 38 (https://afkm.wpafb.af.mil/ASPs/CoP/EntryCoP.asp?Filter=OO-TR-AF-56 39 Some notable information from the current I-NOSC implementation plan is that all migration 40 will be done on a MAJCOM basis in the following manner: 41

I-NOSC-E will be housed at Langley AFB and the following rounds of migration will be 1 implemented beginning 26 March 2008 and ending 15 July 2008: 2

• Round 1 — ACC bases 3

• Round 2 — AFRC bases 4

• Round 3 — AFSOC and AFMC bases 5

• Round 4 — USAFE bases 6

I-NOSC-W will be housed at Peterson AFB and the following rounds of migration will be 8 implemented beginning 26 March 2008 and ending 15 July 2008: 9

• Round 1 — AFSPC bases 10

• Round 2 — AETC bases 11

• Round 3 — AMC and AFMC bases 12

• Round 4 — PACAF bases and Air National Guard (SIPRNET only) for the 13 following: 14

• Cheyenne 15

• Lincoln 16

• McGhee-Tyson 17

• Meridian 18

• Pease 19

• Portland 20

The I-NOSC appendix, along with the migration plan, gives details concerning the migration 22 process: 23

• Security Management — stand up new Active Directory forest and I-NOSC domain 25 to migrate all Active Directory-aware devices 26

• Infrastructure Management — configure infrastructure equipment and Simple 27 Network Management Protocol strings 28

• Mail Relay Management — deploy IP Keyboard-Video-Mouse and migrate Mail 29 Relays into the I-NOSC domain 30

• External DNS Management — stand up and configure stand alone DNS servers at the 31

I-NOSC 32

• Web Proxy Management — configure firewalls and base proxy for management 33 traffic from I-NOSC 34

• VPS Management — set up Enterprise Telephony Management servers at I-NOSC 35 and migrate MAJCOMs into it 36

• IPS Management — build and configure SiteProtector at I-NOSC 37

• Operations Operating Budget Management — configure remote site appliances and 38 update firewalls to allow communications between I-NOSC element managers and 39 remote site appliances 40

6.13 Enterprise IT Service Desk Initiative (formerly Consolidated Help Desk 1

(CHD)) 2

The goal of the ESD is to consolidate 121 existing base NCC help desk operations into four 3 separate locations that are virtualized into one consolidated environment. The ESD will be 4 assigned to 67 NWW. The four physical operating locations identified for virtualized ESD are 5 San Antonio, Ramstein, Gunter, and Hickam. Finalized ESD beddown locations will be 6 governed by Air Force Instruction (AFI) 10-503, Base Unit Beddown Program, 29 May 2003 7 and formally assessed by ACC/A5B. 8 The current scope of this function is limited to the core services [as defined in AFI 33-115, 10 Volume 1, Network Operations (NETOPS), 24 May 2006] of a typical base NCC help desk. It 11 does not include functional or base-unique issues such as Integrated Maintenance Data System 12 (previously Core Automated Maintenance System). This construct includes all active duty and 13 reserve Air Force bases and the AFDW, to support help desk operations based on a standard 14 level of service for both NIPRNET and SIPRNET. ESD operations should include the host base 15 support required for tenant units of combatant commands, other unified commands, and a variety 16 of different tenant organizations currently supported by the base NCC as the customer base 17 traverses the Air Force network. Deployed theater operations and the Air National Guard will be 18 considered at a later date. 19 Consolidation efforts will occur in two phases. IOC is defined as an initial help desk 21 virtualization between San Antonio and Ramstein with the ability to provide help desk support in 22 either location. AETC, PACAF, and USAFE will be the first MAJCOMs to utilize the ESD. 23 AETC and USAFE have already begun consolidated help desk efforts accelerating their 24 movement into the ESD environment. Other MAJCOMs will migrate in as the other ESD 25 locations come on line according to the AFNetOps Battle Rhythm. FOC will occur when all 26 current help desk operations are migrated to one of the four physical ESD locations and the four 27 locations are effectively virtualized into one help desk. 28 The ESD will publish a standard level of service describing how it will resolve issues using a 30 four-tier system for trouble ticket resolution. 31

• Tier 0 will be self-help. Users will consult a knowledge base repository to solve their 33 own problems, i.e., loading printers, updating Global Access List entries, resetting 34 passwords. Any problem not resolved through user self-help will reach Tier 1. 35

• In Tier 1, the ESD will generate a trouble ticket and be responsible for it until 37 problem resolution. This trouble ticket will consist of a standard list of required 38 information concerning the problem and customer. It will be routed by the ESD staff 39 to one of two levels depending on the severity 40

• Tier 1 Level 1 is contained within the ESD and is used for basic troubleshooting 41 with a turnaround goal of 5 minutes or less. 42

• Tier 1 Level 2 is also within the ESD, but is for advanced situations that cannot 43 meet the 5-minute turnaround. 44

• If a problem cannot be solved by the ESD through remote desktop administration or 1 other network tools, it will be escalated to Tier 2, where another entity will be 2 assigned the problem. These entities could include Client Support Administrator, 3 MCCC, etc., that have physical access to the equipment. 4

Finally, any problem not resolved by the lower tiers, will be passed to Tier 3, where specialized 6 expertise consisting of engineers, vendors, etc., will be responsible for resolving the issue. 7 The ESD appendix lists responsibility within its service catalog along with expected response 9 times based upon the problem’s assigned category level. 10

6.14 Service Oriented Architecture Initial Infrastructure Build (SOA IIB) 11 SAF/XCT is currently leading an effort to build the SOA IIB at the Scott APC, to be operational 12 June 2008. This will provide the initial SOA infrastructure that will become part of the overall 13 APC infrastructure baseline. The SOA IIB will provide an environment where processes are 14 supported by information assets delivered through content delivery services. Net-centric tools 15 and protocols allow federating and reusing of content delivery and core services for multiple 16 users, domains, and information sources. Semantic indexing and searching enable the discovery 17 of services through the use of a Metadata Environment. Applications taking advantage of the 18 SOA environment can realize benefits such as reduced costs and increased quality through the 19 reuse of existing services. Capabilities will not be moved to the APCs in one “big bang” event; 20 the intent is to follow an evolutionary approach. At first, core services and limited applications 21 will migrate to the APCs as part of the SOA environment. In the future, more applications will 22 continue to migrate in and undergo changes to better incorporate into the SOA. 23

6.15 Functional Mission Application Migration Plan 24

While the SOA environment is poised to offer many benefits, applications should only migrate 25 when those benefits (i.e., mission effectiveness and cost reduction) outweigh the risks involved. 26 Even then, the migration may take the form of a phased approach. Initially, the application may 27 move into the SOA environment with little or no changes that will allow it to use the services 28 provided, but only if the application met certain criteria, such as it being a high priority to where 29 risk of down time is unacceptable. From there, the application can operate and incrementally 30 transition to a SOA capable application. However, where acceptable, the application may 31 undergo structural changes to make it SOA capable before its migration to the APCs, such as 32 when the application is early in development. In either case, migration will be a progressive, 33 incremental process as overall replacement of IT systems is not economically feasible. 34 Application migration will be considered on a case-by-case basis, dependant upon funding and 36 APC capabilities, until all APCs become capable of hosting all applications (FY12). The process 37 will require identifying applications and owners along with eliminating redundancies. 38 Applications will need to be prioritized and analyzed to determine the changes required for 39 migration. Individual transition plans will be developed for each application before migration, 40 and each applications will be analyzed after migration before shutting down original equipment. 41

6.16 Cross Domain Solutions (CDS) Migration Plan 1

Due to the expense and complexity of certification accreditation, CDS will not transition to 2 APCs or enterprise solutions from their current location until each becomes obsolete. 3 Obsolescence is determined by the Unified Cross Domain Management Office and detailed on 4 their sunset list. As the guard is scheduled for decommissioning if there is not a Defense 5 Information Systems Agency (DISA) enterprise solution available, the customer will purchase 6 the replacement guard and fund its certification at the APC which serves the customer. After 7 certification and accreditation is complete, the APC will pursue a Program Objective 8 Memorandum for future funding for operations and maintenance. CDSs that can be replaced by 9 DISA enterprise solutions and scheduled for retirement will contract with DISA for those 10 services. The Air Force CDS Office (AFCA/EA) will monitor this process and assist users to the 11 best resolution. 12

7 ROLES AND RESPONSIBILITIES 13

In August 2007, ACC provided a Memorandum of Agreement (MOA) outlining the roles and 14 responsibilities of MAJCOMs and ACC (in regards to AFNetOps) to ensure a successful 15 transition of responsibilities, manpower, and other resources in support of AFNetOps. This 16 MOA was amended based on 5 Mar 07 coordination with MAJCOM/CCs and was approved by 17 AETC, AFRC, AFMC, USAFE, AMC, AFSPC, and PACAF in Fall 2007. The MOA is in effect 18 for 2 years. A copy of the AFNetOps MOA is provided in Attachment 2. It is important to 19 acknowledge that there were a few MAJCOM-specific provisions added to the signed versions of 20 the proposed MOA. 21

8 RISK MANAGEMENT 22

Risks are being considered and managed by the AFNetOps team and implementing agents to 23 ensure continued service and minimized disruption to users during the phased implementation. 24 Testing of all capabilities will be accomplished prior to deployment on operational networks and 25 documented lessons learned are being prepared to standardize approaches. The AFNetOps 26 Integration Office is working across the programs and agencies delivering AFNetOps 27 capabilities to identify dependencies, gaps, and overlap and ensure synchronized delivery of 28 capabilities according to mission needs and priorities. As part of the APC design, the enterprise 29 storage capability will provide COOP, data replication, and failover capabilities for disaster 30 recovery at synchronized, mirrored backup sites. Additionally, AFCA is performing bandwidth 31 analysis of traffic before and after user migration to the single AF forest to estimate and plan for 32 bandwidth upgrades required as the user traffic now must travel to/from the nearest available 33 APC for their core services. 34

9 MANPOWER 35

AFNetOps manpower allocations are specified in the USAF PAD 7-10. Personnel movements 36 and manpower reallocations are being worked by SAF/XC. Manpower allocation details, 37 released by SAF/XCTF and validated by 3 MRS, are provided for each AFNetOps operational 38 node in the appendices (i.e., APC, I-NOSC, ESU, ESD). 39

10 AFNETOPS BATTLE RHYTHM PROJECT PLAN 40

For a more detailed look at implementation of AFNetOps capabilities, see the IMS at 41 (https://afkm.wpafb.af.mil/ASPs/CoP/EntryCoP.asp?Filter=OO-TR-AF-56). This details the battle 42 rhythm for transition to the AFNetOps construct. This battle rhythm is a high-level plan of 1 expected completion dates for major milestones of the project and will be refined and updated as 2 required. 3

11 GLOSSARY…