(U) Annex_K_Cloud_Business_Guidance_v5.2.pdf

UNCLASSIFIED

ANNEX K:

CLOUD BUSINESS GUIDANCE

Version 5.2 30 June 2018

Annex K: Cloud Business Guidance i

TABLE OF CONTENTS

Section Description Page

1.0 Introduction

2.0 Cloud Budgeting Practices

2.1 GUIDANCE

3.0 Cloud Financial Planning

3.1 GUIDANCE

4.0 Enterprise Service Authorization

4.1 GUIDANCE

4.1.1 Enterprise Service Identification

4.1.2 Funding and Sustainment

4.1.3 Assessment and Authorization

4.1.4 Lifecycle and Evolution

4.1.5 Retirement

5.0 Cloud Environment Provisioning

5.1 GUIDANCE

5.1.1 Preparedness - Launch (Phase 1)

5.1.2 Readiness - Architecture and Security Onboarding TEMs (Phase 2)

5.1.3 Implementation (Phase 3)

6.0 Cloud Billing and Monitoring

6.1 GUIDANCE

7.0 Activity Optimization

7.1 GUIDANCE

8.0 Cloud Software Lifecycle and Licensing

8.1 GUIDANCE

8.1.1 Planning

8.1.2 Operations

8.1.3 Retirement

Appendix A - Program Build Milestones and Events

Appendix B - Service Lifecycle Artifacts

Appendix C – Mapping Traceability ii

Appendix D - Software License Definitions

List of Figures

Figure Description Page

Figure 4-1 - Service Alignment

Figure 4-2 - Inherited Security Requirements

Figure 4-3 - Technology Obsolescence (S-curve)

Figure 5-1 - Provisioning Process Flow

Figure 5-2 - IATT Process Flow

Figure 6-1 - Billing Alert Threshold Worksheet

Figure 6-2 - C2S Monthly Bill Format

Figure 7-1 - Trusted Advisor Dashboard

Figure A-1 – Program Build Schedule (Nominal)

Figure B-1 – Cloud Enterprise Framework Services

Figure B-2 – Mapped Missions to Capability Threads

Figure B-3 – Service Requirements and Metadata

Figure B-4 – Capability Framework Over Time

Figure B-5 – Enterprise Schedule, Roadmap, and Value Over Time

Figure B-6 – Tech Lifecycle S-curve

Figure B-7 – Inserting a System into the Framework

Figure B-8 – General Service Requirement Inheritance

Figure C-1 – Missions Mapped to Services

Figure C-2 – Metadata Associated with a Service

Figure C-3 – Value to Missions or Capabilities

Figure C-4 – Capability and Value Roadmaps

Figure C-5 – Mapping Services to Capabilities using Architecture Frameworks

List of Tables

Table Description Page

Table 8-1 – CAT Software Asset Form (Example) https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/Annex%20K/D_Annex%20K%20Cloud%20Business%20Models_v5%20NumberTest2.docx#_Toc497823711 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/Annex%20K/D_Annex%20K%20Cloud%20Business%20Models_v5%20NumberTest2.docx#_Toc497823712 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/Annex%20K/D_Annex%20K%20Cloud%20Business%20Models_v5%20NumberTest2.docx#_Toc497823713 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/Annex%20K/D_Annex%20K%20Cloud%20Business%20Models_v5%20NumberTest2.docx#_Toc497823714

Annex K: Cloud Business Guidance

1.0 INTRODUCTION

This Annex provides NGA’s guidance on business practices in support of transitioning and cloud-native development activities. The Annex is a collection of specific business topics that are in-tended to provide subject context, implementation procedures and anticipated outcomes for cloud business operations. These business topics are identified in the following Table.

Section Business Topic

2.0 Cloud Budgeting Practices

3.0 Cloud Financial Planning

4.0 Enterprise Service Authorization (and Lifecycle)

5.0 Cloud Environment Provisioning

6.0 Cloud Billing and Monitoring

7.0 Activity Optimization

8.0 Cloud Software Lifecycle and Licensing

2.0 CLOUD BUDGETING PRACTICES

This section provides an overview of NGA’s budgeting and financial management practices for a cloud environment. It identifies the methods how NGA will operate and manage cloud-based In-formation Technology (IT) from a business perspective.

The key cloud operational objectives are to increase analytic performance and realize reductions in overall infrastructure costs.1 When designed and implemented properly, a cloud computing business model should effect:

Improved IT resource management through on demand Cloud Service Provider (CSP) ser-vices and performance metrics

Increased focus on geospatial mission services via IT infrastructure economies Better NGA financial data tracking and Future Years Defense Program (FYDP) planning Better IT operations management

Efficient financial management of cloud-based services necessitates a commitment to greater transparency in the budgeting and allocation of IT resources. The quest for fiscal IT efficiencies reinforces the need to adjust to the cloud business model. NGA will apply the accounting processes associated with IC ITE capabilities for generating GEOINT services. As NGA incorporates the CSP services, funding process adjustments may be required. Program Managers (PMs) and cross-functional budgeting teams will assess and recommend business model changes (e.g., acquisition, contracting, and budgeting) for GEOINT services. The PMs and the Financial Management (FM) Directorate will adjudicate the budget authorizations and the Full Time Equivalent (FTE) contractor labor expenditure allocations by program.

2.1 GUIDANCE

Guidance: The NGA Program Build should clearly identify cloud development and operations costs.

1 DNI Memorandum E/S 00564, Guiding Principles for Implementing and Operating in a Common Intelligence Com-munity Information Technology Enterprise https://ngaonline.titanium.rttitanium.nima.ic.gov/teamsites/SEIN_IC_ITE/Shared%20Documents/NGA%20Cloud%20Strategic%20Engineering%20Plan/Reference%20Documents/Guiding%20Principles%20for%20Implementing%20and%20Operating%20in%20a%20Common%20IC%20IT%20Enterprise%20(ES%2000564).pdf https://ngaonline.titanium.rttitanium.nima.ic.gov/teamsites/SEIN_IC_ITE/Shared%20Documents/NGA%20Cloud%20Strategic%20Engineering%20Plan/Reference%20Documents/Guiding%20Principles%20for%20Implementing%20and%20Operating%20in%20a%20Common%20IC%20IT%20Enterprise%20(ES%2000564).pdf

Guidance: Program Managers shall maintain cloud performance and cost data for the program and costs will be readily available to Financial Management (FM).

The Program Build should provide transparency into the allocation of NGA funds and should in-clude cloud maintainability and sustainment resource requirements. The Program Build supports NGA missions aligned with defined FYDP goals and is composed of a sequence of milestones and fiscal planning events (see Appendix A - Program Build Milestones and Events). The Re-source & Capabilities Working Group provides a list of investments for the current year Presi-dent’s Budget baseline, approved by the Director, along with approved offsets (divestments) to assure compliance with oversight guidance and controls.

The Cloud PMO and CUO teams provide detailed cost and resource utilization data reports for each program to show utilization and data consumption for PMs to review and make resource adjust-ments. The PMs are required to provide data on cloud usage and costs to the FM Directorate. This data provides the necessary fiscal data fidelity, at the activity level to ensure decision makers have the necessary information to make informed budget decisions.

Guidance: If the program needs additional funding in the year of execution, the PM should prepare a business case and an Unfunded Requirement (UFR) for leadership to adjudicate.

If the Directorate cannot take care of the need; then, submit the business case and UFR for a lead-ership decision, on a priority basis, that need against other corporate UFRs.

Guidance: FM should issue programming guidance and aid in resolving funding shortfalls via UFR approval and follow up once a UFR is approved by the program’s directorate or leadership.

The PM, in coordination with their FM representative, should maintain a structured process for identifying and the allocation of funds for existing and planned development and operations costs, to include cloud migration and operating costs. Cloud resource planning should be derived from the following estimating methods: analogy, parametric, engineering, and actual costs. The FM is to ensure that funding is available for both cloud development and sustainment in the out-years.

Guidance: Program Managers shall be responsible for the management of the program’s cloud de-velopment and operations costs.

The PM shall consider the following cost measures for managing the cloud budgeting process:

C2S billing for each program Managing computing and storage costs (i.e., usage of C2S tools) Resources needed for cloud transition and operating costs Resources needed to build cloud portability Resources needed to decompose data into decoupled data services Program license needs via enterprise environment Dependencies to other programs and services, including other agencies

Scalability of services for mission and delivery environment

NGA via the CSP, provides detailed cost and resource utilization data for each program to show utilization and data consumption for use by programs to forecast future resource needs and to make necessary adjustments.

Performance metrics are to be used to detect problems, support decisions, and gauge the health of the program. Programs have ready access to system performance data to enable the PM to proac-tively manage cloud expenditures, through informed cloud service adjustments.

Performance metrics are a critical component to the program’s business management. These metrics include information such as distinct user consumption/need, capacity, and resource utili-zation. CIO-T uses metrics in its cloud resource and operations support, as appropriate.

Guidance: The Program Budget Review (PBR) stakeholders shall have oversight responsibility of the mission alignment and budgeting of the resources for IT programs.

The PBR goal for the Program Build is to ensure a clear and transparent process for ensuring the best alignment of resources to achieve GEOINT services and mission support. The Advanced, Technical, Leadership, Analytical Suite (ATLAS) FM View contains the PBR Tool for documenting the invest, divest, and realignment throughout the program build process. The cloud costs include all NGA cloud transition and operations costs, as well as, the integration of the cloud environment across the National System for Geospatial Intelligence (NSG), the DoD Joint Information Environ-ment (JIE) and IC Information Technology Enterprise (IC ITE).

Guidance: The current IT business structure shall continue; including the associated processing of receipts, distribution of funding, and reports on contract performance and spending rates.

NGA uses established processes to manage the business and financial aspects of IC ITE services and reporting. NGA applies the budget-based funding model, supported by the Intelligence Plan-ning, Programming, Budgeting and Execution System (IPPBES). The NGA accounting process will be modified where necessary to allow for the easy identification and utilization of cloud cost re-sources by program.

The IC business model for IC ITE is based on a provider-consumer relationship in which the budg-ets to pay for IC ITE services reside with the consumers. IC ITE service providers are to be funded through customer payments, either by an approved cost allocation methodology for enterprise services, by a cost recovery solution (i.e., unit pricing) for commodity services, or through direct payments onto a multi-agency contract (e.g., C2S).

The CIO-T requirements management process ensures requirements are catalogued, reviewed and prioritized in coordination with the community. These requirements and costs will be validated and when approved, prioritized for resourcing as part of the yearly IPPBES workflow.

3.0 CLOUD FINANCIAL PLANNING

This section identifies the financial components of a cloud-based program and the methods/tools available for cost estimation. Prior to initiating cloud migration or a cloud-native program devel-opment good financial planning ensures a proper allocation of resources.

The first step in planning for cloud costs is to determine current IT related costs. Programs are to use the total infrastructure and application support funding for the procurement of cloud services and any additional funds anticipated for cloud migration. Relevant IT expenditures include:

Infrastructure Service Provider (ISP) costs - ISPs provide compute, storage, network communications, and backup services. In the NGA data center environment, ISP expend-itures were typically paid to NCE AIT and/or NCW IT/IS contractors. In the cloud, the CSP provides these services, which will be consumed and costed via variable usage fees.

https://mydata.coe.ic.gov/ee/request/folder?id=41238

Application Service Provider (ASP) costs - ASP costs are associated with software de-velopment and upgrades. These services are typically provided by a development con-tractor other than the ISP. In the cloud, the ASP development and test environments should be provided by the CSP as part of its services.

Software Licensing costs - The NGA Software Asset Management (SAM) Office is the resource for determining associated licensing costs. Approved software for the cloud can be found in the SWAP List or via discussion with the SAM Office.

Miscellaneous costs - Miscellaneous costs are associated with software development, operations and maintenance that have not been planned. Mission-driven changes in ca-pability, capacity, and footprint that were unplanned are contributors to miscellaneous costs.

In the cloud, it can be expected that much of the ISP costs are to be apportioned directly into CSP costs. The majority of the ASP services costs remain with the ASP, with the exception of cloud-as-sociated infrastructure costs which are to be transferred from the ASP to the CSP. ASPs are to pro-vision their DevOps environments from CSP commodity resources.

CSP service costs are accrued on an on-demand, pay-for-use basis. Cloud services are to be provi-sioned on an as-needed basis, based upon developer and mission user requirements. This cost model is quite different from the native data center environment where costs are amortized over time regardless of utilization. Identification of actual DevOps utilization patterns and performance over time can provide the inputs for prudent planning and optimization of IT resources in a cloud environment.

NGA enterprise services (i.e., base services) are provided at no charge and are not included in the cost calculator. Likewise, GEOINT customers consume these services at no charge.

3.1 GUIDANCE

Guidance: Program Managers shall use the Cost Calculator to estimate monthly CSP costs.

Guidance: Cost responsibility for GEOINT consumer usage should be considered in infrastructure siz-ing and as part of the cost calculator inputs.

The PM is to use the CSPs current Cost Calculator which can be found on the NGA Cloud Infor-mation Portal. The Cost Calculator spreadsheet contains content examples on how the form should be filled out. Please note that each domain and cloud have their own unique cost calculators, com-plete with their own unique service pricing model. It is imperative that the proper cost calculator be used when estimating costs for each cloud domain.

The cost calculator provides the most current service charge rates (i.e., periodic updates) for the CSPs available Amazon Web Services. Actual monthly charges will be based upon the metered us-age of the delivered services and may vary from the estimates provided by the calculator. NGA’s cloud support staff are available for assistance in applying data to the cost calculator.

The Cloud Enterprise Services Catalog, located in the ATLAS contains the complete listing of NGA and CSP services.

Guidance: Cloud financial billings shall be managed for two environments, development with testing, and operations.

http://swap.nga.ic.gov/ https://ngaonline/sites/CIO-T/TC/TCS/pages/default.aspx http://www.c2shome.ic.gov/pricing-calculator/ https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Phase%201.aspx https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Phase%201.aspx http://ndegsnarwvapp02.titanium.rttitanium.nima.ic.gov/ibmcognos/cgi-bin/cognosisapi.dll?b_action=cognosViewer&ui.action=run&ui.object=%2fcontent%2ffolder%5b%40name%3d%27NEAR%27%5d%2ffolder%5b%40name%3d%27Domains%27%5d%2ffolder%5b%40name%3d%27ESC%27%5d%2freport%5b%40name%3d%27ESC%20Cloud%20Services%27%5d&ui.name=ESC%20Cloud%20Services&run.outputFormat=PDF&run.prompt=true https://mydata.coe.ic.gov/ee/request/folder?id=41238

IC and DoD fiscal appropriations management necessitates that development with testing and the operational environments’ respective costs estimates and expenditure billings be managed sepa-rately. This requires two separate cost calculator submissions. The type of funding (i.e., O&M, RDT&E, PDW) needs to be differentiated in the allocation of funds. Attention should be given to the unique requirements of each environment, specifically the number of users and hours of oper-ations.

The AF Form 9, which is equivalent to an Independent Government Cost Estimate (IGCE), needs to be processes for allocating CSP funds. The C2S contract requires certified funding for all C2S ser-vices for the entire period of performance. The AF Form 9 must pass PRISM/GEO-F validation and be routed in PRISM for approval in order to be added to the C2S contract. The C2S CLIN Agree-ment provides the domain and period of performance CLIN for C2S usage and training.

4.0 ENTERPRISE SERVICE AUTHORIZATION

This section describes how a given service fits in context of the enterprise. All common IC services are inherently enterprise services. All services follow essentially the same life cycle (e.g., ITIL), and are registered and catalogued. GEOINT services are NGA’s valued enterprise services given their availability to multiple users, common data sharing, and multi-mission support.

Enterprise Systems Engineering & Integration2 (ESE&I) is responsible for the integrating activity which develops and maintains the enterprise baseline. Additional detail on the ESE&I-managed NGA service lifecycle and systems engineering are provided in Appendix B and Appendix C, re-spectively.

4.1 GUIDANCE

4.1.1 Enterprise Service Identification

Guidance: Enterprise service candidates should be registered in the enterprise registry via Service Registry Board (SRB) action.

Enterprise service candidates can be identified or nominated in a variety of ways, all of which re-sult in a disposition of being either a service or enterprise service. The Service Registry Board (SRB) is NGA’s control board for deciding if a nominated service becomes an enterprise service.

The SRB represents the chief engineer and is responsible within ESE&I for maintaining the enter-prise service registry and performs the adjudication of enterprise service nominations.

Guidance: NGA services should meet the general service requirements (GSR) portion of the NGA re-quirements baseline.

All NGA services must incorporate the following GSR information:

1. Alignment with NGA’s architecture reference model (per JARM’s TST notation)

2. Applies, as a minimum:

a. Common requirements from the enterprise (e.g., security, detached data, APIs).

b. Accredited service creation process and tools (i.e., Risk Evaluation Acceleration Man-agement Process (REvAMP))

2 ESE&I provides engineering integration, maintains NGA’s enterprise baseline, and handles the technical aspects of NGA enterprise governance.

https://intelshare.intelink.ic.gov/sites/nga-cloud/Shared%20Documents/Cloud%20AF9%20Guidance%20OY03%20V1.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/Shared%20Documents/Cloud%20Leadership%20Team/Document%20Repository/C2S%20CLIN%20Agreement%20Letter%2020170403.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/Shared%20Documents/Cloud%20Leadership%20Team/Document%20Repository/C2S%20CLIN%20Agreement%20Letter%2020170403.docx https://ngaonline/sites/CIO-T/CLOUD/DigiT/CAMG%20Meetings/2017%20Meetings/Jul_2017_Meetings/DigiT_12%20Jul%2017/NGA-REvAMP_20170620.pptx

3. Identifies the service type as either program (internal) or enterprise (external) use

4. Administrative data (e.g., POC, service dates, functional description, funding source).

Guidance: NGA services should be issued a registry ID and be published in the online and offline ser-vice registries.

The NGA service registration process identifies new services which perform similar functionality in existing enterprise or program-centric services. Registrants may be notified to coordinate with other service developers to collapse or pursue joint service efforts. Adjudication of service col-lapse, joint, or other determinations and waiver requests are performed by the SRB. The SRB may also identify program services as enterprise candidates. The SRB examines new service registra-tions for overall value:

• User need or demand (e.g., priority)

• Overlapping service functionality (i.e., TST)

• Aligned with enterprise strategy (e.g., multi-use)

The SRB will confirm the initial registry ID or initiate the adjudication action. Viable service candi-dates to be “cloud ready” must incorporate the necessary GSR criteria and service information. Re-dundant services may be collapsed into, or replaced by, an enterprise service.

All new efforts are to be cloud-based services and waivers will be required for other solutions.

GSR waivers and/or time constraints on temporary services can be levied by the SRB. Services may be encapsulated in an “accredited container” which supports the GSR via a waiver.

Services identified via redundancy analysis should have all redundant candidates evaluated against one-another and against the possibility of a ‘new start’ service. Such AoAs are to consider “time-to-capability” and mission value.

4.1.2 Funding and Sustainment

Guidance: Programs shall be responsible for services support and funding, while ESE&I should main-tain the mapping of mission-to-service-to-program for funding viability and planning.

Services are assigned to a mission activity via a program’s capability alignment. Services are aligned as either enterprise or private services, and mapped to funding as billing line-items associ-ated with their programs, as follows:

1. Development and test

2. Operations

Services are mapped to the JARM layer and one or more mission capabilities for requirements tracea-bility in POM and FYDP activity planning, as shown in Figure 4-1.

The development and “in-service” capability change dates (i.e., ATO, IOC, FOC) are used by ESE&I to trace the service’s capability evolution over time. The results are used planning purposes for sustaining or adjusting program funding.

Figure 4-1 - Service Alignment

4.1.3 Assessment and Authorization

Guidance: NGA services will perform the Assessment & Authorization (A&A) process in accordance with ICD 503.

Guidance: NGA services will use common standards and reciprocity in accordance with ICD 503.

Guidance: NGA services will weigh the application of protective security measures against delivering mission capabilities at acceptable risk levels.

The Assessment & Authorization (A&A) process for IC systems and services is managed under the IC policy established in ICD 503, IC IT Systems Security Risk Management, Certification and Accredi-tation. In determining the level of acceptable operational risk at a particular security level, appro-priate weight to mission and security requirements, information sharing, collaboration, and other relevant policy requirements must be evaluated. NGA is applying the REvAMP approach to its A&A security risk management.

Statement of Work (SOW) requirements are to include those for service Assessment & Authoriza-tion. Security requirements are to be tagged as security related in the GSR database, as well as those tagged as security-related in the SOW. Services may inherit the certification of services (i.e., C2S-accredited ISP services). As such, the framework on which the software runs, or services the software calls, being certified and accredited by the respective service provider can be ap-plied through inheritance. This is particularly useful when COTS or GOTS function can be in-corporated as a service component, which is al-ready certified.

Figure 4-2 illustrates the scope of inheritance of requirements from the service’s multiple GSR functional layers. The overall service A&A requirements are a combination of standards, unique capability features, security, and per-formance requirements for the service.

4.1.4 Lifecycle and Evolution

Guidance: Program Managers should register services as early in the lifecycle as practical.

Services should reflect the forecasted “in-service” and capability dates for the expected service lifecycle. The early identification of service capabilities helps the SRB with new start adjudication (e.g., service redundancy) as well as FYDP pre-coordination and funding.

Guidance: Program Managers should consult with the SRB and/or review the registry for current or scheduled services with similar functionality.

Services should consider development collaboration options (e.g., incorporating lessons-learned, or code re-use) during the service’s concept and definition phases.

Guidance: Services should be registered prior to operations deployment.

Figure 4-2 - Inherited Security Requirements https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/CIO-T/TS/TSR/Governance/ODNI/ICD%20503%20-%20Intelligence%20Community%20Information%20Technology%20Systems%20Security%20Risk%20Management,%20Certification%20and%20Accreditation%5b1%5d.pdf https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/CIO-T/TS/TSR/Governance/ODNI/ICD%20503%20-%20Intelligence%20Community%20Information%20Technology%20Systems%20Security%20Risk%20Management,%20Certification%20and%20Accreditation%5b1%5d.pdf https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/CIO-T/TS/TSR/Governance/ODNI/ICD%20503%20-%20Intelligence%20Community%20Information%20Technology%20Systems%20Security%20Risk%20Management,%20Certification%20and%20Accreditation%5b1%5d.pdf

Enterprise services operations may require additional IC ITE testing (e.g., common services) and community notification. The switchover from legacy infrastructures may require Community co-ordination prior to deployment (e.g., extended mission users).

Guidance: Services shall provide configuration management during operational deployment.

Operational users may be running on older versions of the deployed services or subject to net-working constraints (e.g., cross-domain employment, extended users). Therefore, services are to:

• Ensure backward compatibility with prior APIs

• Support at least one version prior to the most current

• Notify users of significant functional changes and planned outages

• Provide reversible transitions between significant functional changes to minimize opera-tional disruption. Note that load-balancing to transition between versions is the recom-mended approach.

4.1.5 Retirement

Guidance: Services shall provide sustained, effective mission value to their users during operational deployment or be assessed for retirement.

Retirement decisions are to be based on the mission value, technology obsolesce, and operational sustainment. Ser-vices contribute to mission value via their level of enter-prise support to missions. Technological obsolescence is described as an ‘S-curve’ (see Figure 4-3) where contin-ued investment becomes marginally less useful. This is di-rectly applicable to infrastructure investments (e.g., data centers).

For the NGA cloud enterprise, continued investment in services to support a mission is driven by effectiveness to the mission and minimizing infrastructure investments. At some point in time, services may not be improved but may only be sustained operationally based on preserving mission value. Obsolete services will be dis-continued in favor of services farther down on their S-curve with increased capability value to the mission. Mission stakeholder and user notifications are to be part of the retirement process when a service is being assessed for retirement.

ESE&I is responsible for documenting service capabilities and enterprise value for assessing re-tirement decisions.

5.0 CLOUD ENVIRONMENT PROVISIONING

This section identifies the necessary actions for the provisioning of an activity’s Virtual Private Cloud (VPC). VPCs serve as the cloud’s computational environment for the activity. Provisioning refers to preparing the VPC for use. Provisioning is complete once the user has been authorized and the VPC configured. Responsibilities for VPC preparation and provisioning are shared be-tween:

Cloud Service Provider (CSP) (i.e., C2S)

Stakeholders (e.g., Program Manager)

Figure 4-3 - Technology Obsolescence (S-curve)

Cloud PMO

5.1 GUIDANCE

5.1.1 Preparedness - Launch (Phase 1)

Guidance: Program Managers and developers shall prepare the requisite architecture artifacts to ensure that the service implementation and software components are correctly described and config-ured for cloud implementation.

The activity’s provisioning process begins with the “Launch” (Phase 1). Phase 1 actions are largely the responsibility of the PM to prepare the requisite set of documentation for the Architecture Technical Exchange Meeting (TEM) with the Cloud team. The required Architecture TEM docu-ments are as follows:

Cloud Adoption Template (CAT) – provides standard program management and tech-nical data, including points of contact, technical attributes, proposed transition sched-ule, funding details, and required services. Much of this data will be readily available from the PM, FM representative, and security lead.

Concept of Operations (CONOPS) – provides a general system description and pur-pose of the activity, capabilities and requirements satisfied, information (data) types and roles and responsibilities required to develop and implement the activity.

System Security Plan (SSP) – identifies the security attributes to include users, infor-mation types, and environment specifics to include ports and protocols, and security protection policies. This artifact is required for ICD 503 Assessment and Authorization.

The cloud implementation process starts with the submission and review of the Cloud Adoption Template (CAT) (i.e., word, e-form) and other artifacts. The CAT organizes the activity’s prepara-tion for the architectural meeting with the Cloud team. The completed the CAT, CONOPS, SSP, and AF Form 9 are to be forwarded to the Cloud-Info Distro Group for review and scheduling the archi-tecture TEM.3

Templates for all documents are located on the NGA Cloud Information Portal. Assistance can be requested of the Cloud team at #NGA Cloud-Info.

All systems must adhere to the ICD 503 A&A process. The A&A registration meeting is to record the security requirements, key personnel and roles in XACTA. A Security Plan Identification Num-ber (SPID) will be assigned. Registration meetings require a completed registration form (i.e., Ser-vice Oriented Architecture Registration Template), CONOPS and network diagram. PMs must coordinate with their assigned Information System Security Officer (ISSO) for scheduling the meeting. The A&A meeting may be held in concert with the Architecture TEM. Access the XACTA webpage for general A&A information (e.g., templates, workflows) and linkage to the XACTA tool.

Phase 1 implementation requires coordination with the Data Migration Group to identify the data types, sources, and storage interfacing. If development uses the PaaS environment or GEOINT Ser-vices’ tools, coordinate with the GEOINT Services Group.

While not all documents are required to be complete prior to the conducting of the Architecture

3 Phase 1 Checklist https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/CAT%20Form/CAT%20Form%2020170731.docx https://ngaonline/sites/t/Service-Implementation/ti/StrategyFuture/CLOUD_IandA_PMO/CATDocumentSubmissions/SitePages/Home.aspx https://intelshare.intelink.ic.gov/sites/nga-cloud/Shared%20Documents/SharePoint%20Guides_Tutorials/Security%20Approver%20Reference%20docs/OCIO_CONOPS_Template_3JUNE2015.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/Cloud%20Wiki/CIO-T%20Security%20Requirements/CIO_SSP_Template_Nov_2016.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/Shared%20Documents/Cloud%20AF9%20Guidance%20OY03%20V1.docx mailto:Cloud-Info@coe.ic.gov https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Home.aspx mailto:Cloud-Info@coe.ic.gov mailto:Cloud-Info@coe.ic.gov https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/OCIO/Documents/Services/A%20and%20A%20Forms%20and%20Templates/CA_SOA_System_Registration_Template_v6-0_20090225_U.doc https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/OCIO/Documents/Services/A%20and%20A%20Forms%20and%20Templates/CA_SOA_System_Registration_Template_v6-0_20090225_U.doc https://ngaonline.titanium.rttitanium.nima.ic.gov/sites/OCIO/SitePages/Services/Xacta/Xacta.aspx https://ndegsxiawvxim06.titanium.rttitanium.nima.ic.gov/xacta/JopletManager mailto:CloudDataMigrationInventory@nga.ic.gov mailto:GSProjects@coe.ic.gov https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Phase%201.aspx

TEM, the following documents are required for completion of the provisioning process:

E-mail Distribution List – provides the C2S commercial provider with the required contact list for the activity. Each activity must have a Development/Test, and Opera-tions e-mail distribution list to coincide with their separate C2S accounts. Standard naming conventions for Distribution Lists are provided on the NGA Cloud Information Portal.

Roles Spreadsheet – provides the activity’s authorized cloud users and their respec-tive privileges (e.g., read/write, read-only).

Cost Calculator – provides monthly cost estimates for C2S services. Separate and dis-tinct Cost Calculators should be developed for both Development/Test and Operations environments. The Calculator output provides the basis for the funding of cloud ser-vices.

AF Form 9 – provides the specifics regarding certified funding for C2S services. The AF Form 9 demonstrates commitment to operations and support costs and POM planning for full lifecycle costs. AF Form 9s must pass PRISM/GEO-F validation and approval.

Of these documents, the CAT, CONOPS and SSP are required for the Architecture TEM with the Cloud team. These artifacts provide information essential to the efficient sizing, CSP implementa-tion and operation of the activity in the cloud.

5.1.2 Readiness - Architecture and Security Onboarding TEMs (Phase 2)

Guidance: The Cloud Adoption Template (CAT) and the architecture artifacts shall be reviewed at the Architecture TEM to ensure that the service implementation and software components are con-figured and correctly described for cloud implementation.

The Architecture TEM assist in building out the cloud architecture by a technical appraisal of the CONOPS, SSP and software requirements. The Architecture TEM is facilitated by Cloud team repre-sentatives to ensure the cloud implementation process is both understood and expedited. It is es-sential that the PM and technical lead be in attendance. The TEM objective is to provide SME guidance for achieving the “To-Be” cloud architecture, applying the appropriate services from the Cloud Enterprise Services Catalog and finalizing CSP cost estimates. The Architecture TEM coordi-nation is initiated by sending an email to the Cloud-Info distro group. The activity is assigned an Architecture TEM lead and a Delegated Authorizing Official (DAO) as their POCs for handling cloud questions. AWS Technical Account Manager (TAM) representatives are available for any Amazon related questions or concerns. 4

Upon TEM completion, documentation is to be updated for the agreed upon cloud architecture, along with the corresponding cost calculation for review and approval by the Engineering Review Board (ERB). Assessments by two independent reviewers should occur within 48 business hours.

If modifications or waivers are requested, a follow-up submission to the ERB may be required.

If the A&A meeting was not held in concert with the Architecture TEM, the IC ITE Security A&A team and Risk Management need to be contacted to determine the appropriate security controls via a Security Onboarding TEM (SOT).

4 Phase 2 Checklist http://ndegsnarwvapp02.titanium.rttitanium.nima.ic.gov/ibmcognos/cgi-bin/cognosisapi.dll?b_action=cognosViewer&ui.action=run&ui.object=%2fcontent%2ffolder%5b%40name%3d%27NEAR%27%5d%2ffolder%5b%40name%3d%27Domains%27%5d%2ffolder%5b%40name%3d%27ESC%27%5d%2freport%5b%40name%3d%27ESC%20Cloud%20Services%27%5d&ui.name=ESC%20Cloud%20Services&run.outputFormat=PDF&run.prompt=true mailto:Cloud-Info@coe.ic.gov mailto:SEINCAPERB@coe.ic.gov mailto:SEINCAPERB@coe.ic.gov mailto:TSRiskManagementDAORTeam7@coe.ic.gov mailto:TSRiskManagementDAORTeam7@coe.ic.gov https://ngaonline/sites/CIO-T/TS/TSR/Pages/default.aspx https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Phase%202.aspx

The SOT provides the information and tools necessary to efficiently and successfully navigate through the Risk Management Framework (RMF) process.5 This includes:

Overview of the RMF process and general A&A requirements

Specific requirements for the Categorization and Selection TEM (CAST)

The Categorization and Selection TEM (CAST) meeting reviews the data types being processed, re-sulting in the determination of a security categorization value of the Confidentiality, Integrity and Availability for the program; as well as, the applicable security overlay (e.g., H-M-M, INT-A) con-trols. The CAST will address conformance to the enterprise audit requirement, Ports Protocols and Services (PPS), boundary diagram, and the Privacy Threshold Analysis (PTA) form. Programs with an existing SPID will receive a new 6000 series number.

Upon completion of the Architecture and the CAST TEMs, including any provisioning liens, the ac-tivity’s C2S account is established and the Authorization to Proceed (ATP) granted. A process flow diagram for getting an ATP is shown in Figure 5-1. Reference the PM’s Guide to Cloud Migration for the detailed procedures.

Guidance: The completed Cost Calculator shall be attached to the AF Form 9 as evidence for the re-quired funding to establish the CSP (e.g., AWS/C2S) account(s).

Upon completion of required documentation, the Cloud team establishes the AWS/C2S account(s) for the activity (i.e., Dev/Test, Operations). The AF Form 9 must be completed and approved by all required stakeholders prior to account creation. Account requests are made by the Cloud team via the Joint Store Front (JSF) and are “approved” by:

Security (CIO-T/TS) for validity of requested accounts

Business (CIO-T/TIIR) for confirmation of authorized funding

All approvals are required for a C2S account authorization to proceed. Denials result in follow-up actions by the PM.

Upon approval, the Cloud team prepares the necessary cloud instances for the activity, configured per the cloud “To-Be” guidelines. A C2S kick-off meeting is held to discuss VPC maintenance and general C2S operations support, if required. The VPC is now considered in “fully provisioned” sta-tus and available for activity configuration and development by the PM, as shown in Figure 5- 1Error! Reference source not found., with the granting of an ATP.

5 Information Assurance Requirements Catalog (IARC) https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/PMs%20Guide%20to%20Cloud%20Migration-Process%20Templates%20Expert%20Tips-v1-mfarley-032717.docx https://jointstorefront.vm.web.nsa.ic.gov/ https://ngaonline/sites/CIO-T/TS/TSR/Pages/Informational-Documents.aspx

Figure 5-1 - Provisioning Process Flow

An ATP memorandum is prepared to acknowledge the security categorization of the program and formally authorize development for implementing operations in the cloud. Note that no expenses are incurred until the account is used.6

5.1.3 Implementation (Phase 3)

Guidance: Program Managers shall prepare the requisite documentation for IATT and ATO ap-proval.

Provisioning establishes the cloud environment for the activity’s service development and/or op-erations. The VPCs and associated data feeds are maintained by the activity’s development staff via the C2S Access Portal (CAP). The Consolidated Service Portal (CSP) provides the means to gen-erate a request of data transfer and obtain additional C2S services (e.g., cross domain). If GEOAxIS is to be used for authentication, contact the GEOAxIS team to coordinate its integration.

NGA periodically publishes a set of security compliant Amazon Machine Images (AMIs) to be used by NGA programs for their Elastic Compute Cloud (EC2) instances. The AMI provides the neces-sary AWS configuration to launch an EC2 instance with NGA base security, DISA Security Technical Implementation Guides (STIGs), and hardened application configurations applied. It is the respon-sibility of the program to complete all A&A activities.

AMI versions are maintained for two iterations. Any AMIs older than two iterations will not be supported. Additionally, only base AMIs will be supported. Any add/modify/change of the AMI by the program will not be supported by C2S operations. 7

6 Phase 3 Checklist 7 NGA AMI Release Notes https://cap.cia.ic.gov/ http://csp.nga.ic.gov/home/action/2 https://geoaxis.nga.ic.gov/consumers/ mailto:ngaGEOAxISIntegrate@coe.ic.gov https://intelshare.intelink.ic.gov/sites/nga-cloud/SitePages/Phase%203.aspx https://intellipedia.intelink.ic.gov/wiki/NGA_Elastic_Compute_Cloud_Amazon_Machine_Image

5.1.3.1 IATT Process

The required documentation for IATT approval follows:

CONOPS update with a review and incorpora-tion of any Risk Management feedback.

SSP update with Risk Management and TACC feedback.

System Accreditation Plan (SAP) via TACC.

Figure 5-2 shows the document updates required prior to IATT approval (i.e., Draft CONOPS (>80%). Also, the Secu-rity Controls Traceability Matrix (SCTM), Information Sys-tem Control Matrix (ISCM), Access Control Model Framework (ACMF) audit, the Software Assurance Pro-cess (SWAP) artifacts) and a “clean” vulnerability and compliance scan, are the requisite body of evidence (BOE) for the IATT.

Request ACAS vulnerability and compliance scans from the TST Request Portal and to set up a scan. A “clean” scan implies there are no critical or high security findings. All critical or high find-ings are to be mitigated, with the IATT approval or waiver by the DAOR. Reference the PM’s Guide to Cloud Migration for the detailed procedures.

An IATT allows the program to: 1) configure security groups and NACLs for connections outside the VPC, 2) integrate with the ESS services, and 3) begin integration and functional testing.

5.1.3.2 ATO Process

The required documentation for ATO approval follows:

SCTM via Security Audit strategy document per program deployment architecture

Configuration Management Plan (CMP)

Security Control Assessor (SCA) Assessment

Information System Authorization via Security

ATO Decision Brief

The DAO/DAOR will assess the activity's documentation package for the ATO decision. Reference the PM’s Guide to Cloud Migration for the detailed ATO procedures.

6.0 CLOUD BILLING AND MONITORING

This section describes the cloud billing cycle to include sequencing and timing of events, stake-holder roles and responsibilities, and financial dependencies. Responsible parties for a program’s cloud funding, billing, and financial monitoring follow:

Program Manager (PM)

Financial Management (FM)

Commercial Service Provider (CSP)

Figure 5-2 - IATT Process Flow mailto:TSRiskManagementDAORTeam7@coe.ic.gov https://ngaonline/sites/CIO-T/TS/TST/Pages/default.aspx https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/PMs%20Guide%20to%20Cloud%20Migration-Process%20Templates%20Expert%20Tips-v1-mfarley-032717.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/PMs%20Guide%20to%20Cloud%20Migration-Process%20Templates%20Expert%20Tips-v1-mfarley-032717.docx https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/PMs%20Guide%20to%20Cloud%20Migration-Process%20Templates%20Expert%20Tips-v1-mfarley-032717.docx

Cloud Team

6.1 GUIDANCE

Guidance: Program Managers and their Financial Management (FM) representatives shall be re-sponsible for the program’s CSP (e.g., AWS/C2S) account(s) cost management.

Guidance: User role assignments and invoice processing shall be managed by NGA’s Cloud Program Management Office (PMO).

Guidance: Financial Management (FM) shall authorize the release funds to the CSP upon invoice cer-tification.

AWS/C2S costs are available at all times to authorized users via the Amazon provided Cloud Ac-cess Portal (CAP). CAP uses role-based authorization via AccessIT! to grant access to the accounts.

Role assignment is managed by NGA. Each program should have at least a BILLINGMGR role to access the billing data each month. The CAP User Guide provides detailed information on the CAP and troubleshooting suggestions.

C2S accounts are to be registered with CAP and assigned a unique mission name in order to sup-port 'Federated Access' capabilities. CAP provides administrative features that allow NGA to man-age its C2S accounts, user roles, and account settings independently. Account set-up activities are performed by NGA’s Cloud PMO based on requests from the Joint StoreFront (JSF).

Note that with consolidated billing, only the master account can create and manage budgets. Indi-vidual member accounts cannot create or manage budgets; member accounts have read-only ac-cess to budgets in accordance with the Controlled Access policy.

The Billing and Cost Management console and dashboard interface provides authorized users with the AWS/C2S cost data for the program. The console opens to the dashboard, where current month-to-date usage graphs are displayed. The dashboard function allows for easy access to last month’s expenses, current month-to-date costs, as well as budget forecasts based on historical monthly costs (i.e., Cost Explorer).

AWS bills accounts only for usage. To help manage expenditures, AWS provides several easy-to-use features that help account management, including alerts and notifications, cost allocation tags for detailed accounting, and cost optimizing (i.e., Trusted Advisor).

For a cost management example, the CloudWatch billing alarm notifies the manager when costs ex-ceed the set budget threshold, as shown in Figure 6-1. Figure

Trusted Advisor inspects the program’s operating environment and recommends opportunities to save money and improve system performance via best practices. Also, as a cost saving best practice, consult the Design White Paper - Turn Off Com-pute When Not Needed. For more information

Figure 6-1 - Billing Alert Threshold Worksheet https://cap.cia.ic.gov/ https://cap.cia.ic.gov/ https://www.iaa.cloud.coe.ic.gov/iaa-web/ https://cap.cia.ic.gov/docs/user-guide.md#top https://jointstorefront.vm.web.nsa.ic.gov/ http://docs.c2shome.ic.gov/awsaccountbilling/latest/aboutv2/control-access-billing.html https://console.c2shome.ic.gov/billing/home#/.

http://docs.c2shome.ic.gov/awsaccountbilling/latest/aboutv2/monitor-charges.html http://www.c2shome.ic.gov/premiumsupport/trustedadvisor/ https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/SitePages/Guidance/NGA%20Cloud%20Guidance%20v5.2/Design%20White%20Paper%20-%20IaaS-Turn%20Off%20Compute_June_2018.pdf https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/SitePages/Guidance/NGA%20Cloud%20Guidance%20v5.2/Design%20White%20Paper%20-%20IaaS-Turn%20Off%20Compute_June_2018.pdf about budgets, see Managing Your Costs with Budgets.

Costs for CSP services are accrued, invoiced, and paid on a monthly basis, as illustrated in Figure 6-2. The invoices are generated and validated for accuracy, completeness, and available funding by NGA’s Cloud PMO. Once the invoice is deemed accurate, the Cloud PMO certifies the invoice and delivers it to FM for payment. Funds are debited from a program’s available funding.

Figure 6-2 - C2S Monthly Bill Format

7.0 ACTIVITY OPTIMIZATION

This section provides guidance for the PM, developers and service operations staff regarding a program’s cloud activity performance and cost optimization. Key cloud operating principles, as well as, performance metrics and utilization tools will be discussed.

The AWS/C2S provides utilities that monitor performance and service utilization data of its re-sources. Periodic review and analysis of this information enables users to make informed deci-sions on optimizing cloud resources and reducing program costs.

Cloud architectures provide on-demand, elastic provisioning of resources. Properly architected and sized cloud resources can readily meet demand, even under peak operational loading condi-tions. Appropriate sizing of a CSP service often results in significant cost savings. Also, elastic pro-visioning is especially advantageous in development/test environments where use is primarily during business hours. If an instance is turned off, it’s not accruing running charges; however, a fine point is that Elastic Block Storage (EBS) attached to that stopped instance does still accrue charges. Shutting down unused instances (e.g., EC2s) results in noteworthy savings. Consult the Design White Paper - Elastic Block Store for best practice recommendations on reducing EC2 op-erating costs.

7.1 GUIDANCE

Guidance: Program Managers and developers shall not replicate existing legacy infrastructure re-quirements or design configurations in the cloud.

Cloud environments operate differently and more efficiently than legacy data center environ-ments. Replicating non-elastic legacy infrastructures that are designed for “peak use” or “DR back-http://docs.c2shome.ic.gov/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html up” conditions, will result in supporting unnecessary infrastructure, over scaling and increased cost.