Cloud Migration Strategies

The migration process consists of choosing a strategy ("6 R's") and executing a 5 phase plan. The 5 phases are:  Opportunity Evaluation, Portfolio Discovery and Planning, Application Design, Migration & Validation, and Operate.

Phase 1:  Opportunity Evaluation. What is the business case or compelling event that will drive your migration to the cloud? Examples:  data center lease expiration, policy (e.g. FDCCI, DCOI, ADDCP), access to services or features, reduction of expense (increased opex is more beneficial than initial and recurring capex), developer productivity (e.g. reduced wait time for infrastructure provisioning and access to services that don't need to be built), availability, content caching, backups, disaster recovery.

Phase 2:  Portfolio Discovery and Planning. What's in your environment, what are the interdependencies, what will you migrate first, and how will you migrate it? Inspect your configuration management database (CMDB), institutional knowledge, and/or deploy tools (e.g. AWS Discovery Service or RISC Networks). Understand licensing arrangements. For security and costing purposes, it's useful to know:

• What information type(s) are going to be received, processed, stored, transmitted, and/or displayed in the cloud? Refer to NIST SP 800-60 Volume II for guidance.
• What is the footprint for applications that will be re-hosted or re-platformed? This information can be used for cost estimation.
• Are performance metrics available? This information can be used to right-size the environment. Because the cloud has a pay-as-you-go model, there's no need to over provision resources. The architecture can be designed to support the minimal performance requirements and expanded as additional resources are required.
• Consider data gravity. What data belongs with what application? Where the data lives will drive where the application lives and/or how that application access the data. If a large data set is going to be used to perform sporadic analysis work in the cloud (by spinning up 100s of instances), then analyze whether it makes sense to store this data permanently in the cloud, or move it in/out over the wire or via Snowball. If you don't have the bandwidth and the volume is large, the copy/mail (Snowball) approach will be more efficient than a wire transfer.
• What volume of data needs to be transferred into our out of the cloud? This information is needed to design data transfer solutions (e.g. over the wire or out-of-band using Snowball) and also estimate costs for data egress.

Phase 3 and 4:  Designing, Migrating, and Validating Applications. Each application is designed, migrated, and validated using one of the 6 migration strategies. Common infrastructure and security solutions should be design and used, for example identify management (e.g. Active Directory), log collection, configuration management, backups. Low-complexity, low-interdependency applications should migrate first. Have the application owner monitor the migration and validate the results while monitoring costs.

Phase 5:  Modern Operating Model. As applications are migrated, iterate on your process(es) and foundation, decommission old systems, and continue to look for opportunities to achieve efficiencies and/or improvements in cost, labor, and security.

This article has a nice graphic showing 6 migration strategies (although 2 don't count):

• ​​Re-host (lift-and-shift​)
• ​Re-platform (lift-and-reshape)
• ​​​Re​-purchase (replace-drop & shop)​​
• Re-architect (​re-writing/decoupling applications)
• ​Retire/decommission
• ​Revisit/retain

References:

• AWS Cloud Enterprise Strategy Blog:  Considering a Mass Migration to the Cloud? November 1, 2016.
• AWS Cloud Enterprise Strategy Blog:  A Process for Mass Migrations to the Cloud. November 1, 2016.

​

Identity and Access Management (IdAM) (draft)

Identify and Access Management (IdAM or IAM) is the mechanism used to authenticate an entity and authorize them to access a resource.

Several well-known services exist for authentication, including Active Directory, lightweight directory access protocol (LDAP), Remote Authentication Dial-In User Service (RADIUS), Internet Authentication Service (IAS) (Microsoft's implementation of RADIUS), Terminal Access Controller Access-Control System Plus (TACACS+) (Cisco-developed authentication, access, and accounting solution for networking devices), and Network Information Service (NIS). With the proliferation of cloud-based services, cloud service providers are providing identity and access services that are highly-scalable, robust, and secure. Examples include Amazon Web Services (AWS) Identify and Access Management (IAM) and several choices for implementation of Active Directory:  AD Connector, Simple AD, Microsoft AD. Rackspace has a good article which compares the different directory service offerings. Some things to consider in implementing authentication services:

• Managing multiple services is an administrative burden and is not an efficient use of resources. Building a robust service (e.g. Active Directory) and configuring applications to use that service is easier to manage than setting up separate authentication realms. This approach is known as single sign on (SSO) - using one credential to access many services.
• There are several methods to authenticate an entity, such as username/password, smartcard, challenge questions, one-time token, biometric, etc. Use of multifactor authentication (MFA) is highly recommended, which requires something a user knows (e.g. password) and something the user has (e.g. smartcard) or is (e.g. fingerprint).
• Implement a lockout policy and recovery mechanism for lost or forgotten passwords. Examples of solutions for this are:  SysOp Tools Password Reset Pro. For hosted services (e.g. Office 365), use the administrative tools to configure a policy to do this.
• Implement a logging and audit policy to review authentication events. For example, use of privileged accounts, failed access, anomalies in access times and/or geographic location (e.g. a user attempting to login from the US and then 10 seconds later from the UK).

Access management concerns governing permissions and rights to resources once the identity of an entity is verified via the authentication service described above. This is implemented by file system permissions and role definitions and assignment.

Per Department of the Army Pamphlet (PAM) 25-2-7 Information Management:  Army Cybersecurity Army Information System Privileged Access:  DA Form 7789 (Privileged Access Agreement and Acknowledgment of Responsibilities) is required after 4 May 2019. Individuals requiring elevated access to system control, monitoring, administration, criminal investigation, and/or compliance functions must sign a Privileged Access Agreement (PAA). Individuals seeking privileged access must complete and sign a PAA. Categories and specialties within the cybersecurity workforce that require a PAA include:   1) those requiring modification access to the configuration control functions of the IS/network and administration (e.g. user account management), 2) those with access to change control parameters (e.g. routing tables, path priorities, addresses of routers, multiplexers, and other key IS/network equipment or software), 3) those with the ability and authority to control and change program files, and other users' access to data, 4) those with direct access to operating-system-level functions that could permit system controls to be bypassed or changed, 5) those with access and authority to install, configure, monitor, and/or troubleshoot the security monitoring functions of IS/networks, or in the performance of cyber/network defense operations.

PAM, Privileged Access Management (sometimes Privileged Account Management), refers to the oversight of privileged user access to critical data and systems. PAM solutions implement features such as:  access manager (point of entry which facilitates user requests and the administrators' ability to grant and revoke access), password manager (protect, store, and rotate passwords, eliminating the need for users to have direct access to sensitive resources), session manager (trace and monitor privileged activity, automatically or manually terminate and report suspicious activity).

Authentication

• Password policy
• Multi-factor Authentication (MFA)
• Single Sign On (SSO). Minimize the number of credentials needed, authentication realms to manage. Diligently audit in one place. SSO can support MFA for applications that don't.

Authorization

Authorization is the concept controlling what a user is allowed (or not allowed) to do once they

are authenticated. In IAM terms, authentication + authorization = access. 

Governance is the concept of periodically attesting to the appropriateness (or correctness) of user authorizations.

Identity analytics is an emerging discipline of IAM that evaluates the permissions, rights and

entitlements of individuals – and detects anomalies. Identity analytics is an effective way to uncover

errors in provisioning (we’ll call it over-provisioning) and to discover purposeful rights escalation

activities. It can prevent the activities of external bad actors and detect internal risks before they can

become a threat.

• Provisioning. Defining and assign the user to the correct role(s) that provide the necessary rights for them to do their job.
• Deprovisioning. Removing those rights.
• 
  

Identity Solution Providers.

• Auth0. Role-based access control. "Organizations" - allows clients to manage roles. Developer friendly. Note Auth0 was acquired by Okta.

PAM:

• CyberArk.
• Thycotic..
• BeyondTrust. Call 7/26/2021. Nick Shaw, Anthony White (DoD and DHA), Steven Schullo (Solutions Engineer). Endpoint Privilege Management (agent-based. Windows, Mac, Unix. licensed by asset. Number of users doesn't matter. Allows access to privileged functions - process gets elevated vice the user). BeyondInsight (command and control/management auditing), can also control through ePO as well as GPO, can be run on-premise or SaaS in Azure, AWS, GCP, working on FedRAMP ATO, look for BeyondTrust in CSP marketplace). Whitelist, blacklist, and Assistance Required (need code from Service Desk). Only responsible for compute cost., Credentials Required (provide credential as well as reason). Password Safe. Cloud Privilege Broker (coming this summer).
• Wallix

Identity Governance

• SailPoint
• One Identity

​Resources:

• DISA IASE IdAM Program Documentation

Additional References:

• ​​NIST SP 800-53 AC Control Family​​

Relevant Articles:

• End of Passwords:  DISA Tests Walkabout Identify System, Breaking Defense, May 16, 2019

Information Assurance/Cyber Security Resources

DoD

• Cyber Security & Information Systems Information Analysis Center (CSIAC)
• DISA IASE
• Risk Management Framework Knowledge Service (RMFKS)
• Center for Development of Security Excellence (CDSE). Training content in the following topic areas:  Counterintelligence, Cybersecurity, General Security, Industrial Security, Information Security, Insider Threat, Operations Security, Personnel Security, Physical Security, Special Access Programs.
• CDSE Security Awareness Hub​

Army

• AT&CTS
• Information Assurance One Stop Shop (OSS)

Navy

• DIACAP Knowledge Service

​Certification and Training

• (ISC)2​

Preventive Maintenance Program for IT

Preventative maintenance is performed on IT systems in order to resolve issues prior to failure and thus impacting operations. By identifying problems early and conducting periodic repairs and upgrades, savings in cost and labor are realized by avoiding corrective/reactive maintenance activities.

Preventive maintenance is performed regularly on a scheduled basis in order to minimize the chance that a certain piece of IT equipment will fail and cause unscheduled downtime. A bi-weekly after hours maintenance window is established to perform compliance, corrective/repair, and preventive maintenance on IT equipment. Prior to entering the maintenance window, the Operations Lead

prepares a list of activities to be performed during the maintenance window and obtains approval for execution from the Operations Manager. The plan for each maintenance window includes an estimation of time required to performed the planned actions and is prioritized with emphasis on corrective/repair and compliance activities. If the time allocated for the maintenance window does not allow preventive maintenance activities to be performed, our Operations Lead coordinates with the Operations Manager to set a aside a supplemental maintenance period or the actions are planned so as to not disrupt ongoing operations (e.g. replacing failed drives in a RAID that will not require any downtime). We develop the planned list of preventive maintenance activities to be performed during a given maintenance window using:

- Lifecycle Management (LCM) reports are produced weekly. Equipment with an end of support (EOS) or end of life (EOL) date within six months of the current date are flagged for replacement and a determination is made to sustain or retire the equipment or capability. If the equipment is to be retired, we follow a decommissioning process. If the equipment or capability is to be sustained, our engineering team evaluates replacement solutions and prepares an acquisition request which includes budgetary pricing, justification, and implementation plan. 

- Network and system monitoring tools (e.g. SolarWinds) are used to query and log capacity utilization for server CPU, memory, disk, and network resources. For CPU and memory components, additional resources are provisioned if utilization exceeds 70% over a prolonged interval (e.g. not an abnormal spike due to a surge in use). For disk resources, capacity or quota is increased by 20% when a volume reaches 80%. For physical systems, an acquisition request is made for additional hardware required. For virtual systems, hypervisor capacity is analyzed to verify additional resources can be provisioned.

- For systems configured to retain local log files, utilization of local storage is inspected weekly. When utilization exceeds 90%, the oldest events are deleted after verification that logs are being successfully delivered to the security information and event management (SIEM) system.

- SAN and NAS health is analyzed weekly by examining the management interface, logs, and/or alerts. Any disks flagged as failed or failing by the SAN or NAS are replaced. An acquisition is initiated for additional storage when capacity reaches 80%, with the amount of capacity increase determined by analysis of the growth rate and any projections provided by information owners.

- Tier 3 System Administrators, Network Engineers, and Database Administrators monitor vendor web sites and/or newsfeeds to maintain awareness of updates and/or manufacturer recommendations for periodic maintenance for systems they manage Operating system, application, SAN or NAS, switch, router, firewall, or other IT system updates are applied when enhancements to features, stability, and/or performance can be achieved.

- Security Information and Event Management (SIEM) logs and alerts are reviewed to identify indications of potential failures. These could include:  network interface errors indicative of failing hardware, loose connections, or wiring damage, warnings for PKI certificate expiration, equipment temperature or power fluctuations which could indicate failing fans or power supplies. Testing (e.g. wiring) or replacement of components is performed during the scheduled maintenance window.

During the maintenance window, the planned and approved preventive maintenance actions are performed. At the conclusion of the maintenance, the Operations Lead provides a report to the Operations Manager which indicates what activities were successful.

A computerized maintenance management system (CMSS) is recommendation to implement this preventive maintenance program.

Testing Web Server PKI Certificates

Qualys https://www.ssllabs.com will check certificate validity, encryption and hashing algorithms supported, TLS protocols, etc. and assign a grade to a PKI-enabled web server. Use Nartac Software IIS Crypto to configure your server to get an "A"!

References:

• How to Update Your Windows Server Cipher Suite for Better Security, How-To Geek, July 12, 2017.

Containers Versus Virtual Machines

Containers are lightweight alternatives to virtual machines (VMs). Whereas VMs use dedicated virtual resources (disk, CPU, memory, network interface), containers may share common files.

• Kubernetes. Container orchestration (what does orchestration actually mean?)
• Rocket/rkt
• openVZ/Odin (formerly Parallels)
• Docker​

Benefits:

• Portability

Security Considerations:

• Like a Type 2 hypervisor, containers rely on the host operating system. Whereas VMs run their own operating system, containers share the underlying host operating systems. Vulnerabilities in the host OS can affect the containers.
• Certification. Is there a way to ensure the content of the container can be certified and changes tracked? Need a method to establish trust of container. What do we do in the DevSecOps environment to verify what is being deployed is secure? Static code analysis? Dynamic application inspection?
• Snyk brings vulnerability scanning to Docker official and certified images.

References:

• Qualys Blog  Security Container Deployments with Qualys, August 30, 2018
• NIST SP 800-190, "Application Container Security Guide," September 2017
• "6 questions CISOs need to ask about containers," 13 September, 2016

Army Certificate of Networthiness (CoN) Replaced with RMF Assess Only

Per ARCYBER OPORD 2018-097, published April 20, 2018, the RMF Assess Only process will be implemented NLT July 2, 2018 to replace the Army CoN process.The OPORD and NETCOM Operational TTP are both published on the RMF Knowledge Service (RMFKS). Access the link below, for the OPORD see the Orders and Fragos folder, for the TTP see the TTPs folder:

https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/USArmyOperations/Pages/default.aspx

NETCOM Risk Management Framework Assessment Only Operational Tactics, Techniques, and Procedures, Version 1, April 2018 describes the current "Assess Only" process for the Army.  The following is a summary of the guidance.

• The Assess Only process applies to Army Information Technology (IT) that does not meet the Assess and Authorize (e.g. full RMF) criteria as described by DoDI 8510.01. This includes Platform IT (PIT), IT Services (Internal and External), and IT Products (Applications, Software, and Hardware).
• The RMF applies to all DoD IT that receive, process, store, transmit, or display DoD Information (see DoDI 8510.01). DoD Information is any information that has not been cleared for public release and that has been collected, developed, received, transmitted, used, or stored by DoD, or by a non-DoD entity in support of an official DoD activity (DoDD 5230.09). DoD Information is also any official DoD information that pertains to military matters, national security issues, or subjects of significant concern tot he DoD (DoDD 5230.09). 
• The Information System Owner (ISO)/Program Manager (PM) will determine the IT type for the entity being considered for Assess Only by using the IT Type Wizard on the RMF Knowledge Service. Note that a Major Application, which will require Assess & Authorize (A&A), is any application that is a product or deliverable of an Acquisition Category I through III program as defined in Enclosure 1 of DoDI 5000.02 "Operation of the Defense Acquisition System," January 7, 2015.

• The ISO/PM will identify the mission category and the requirements to protect the confidentiality, integrity, and availability (CIA) of the information being processed. The mission category will be assigned a value of:  MISSION SUPPORT, MISSION ESSENTIAL, OR MISSION CRITICAL. Available assignment values for categorization are Low, Moderate, or High for each security objective. Note that depending on the mission category, an application may be designated as a Major Application and thus disqualified for the Assess Only process (e.g. a Support application processing {H,H,H} information types).

• The Assess Only decision process is depicted as follows.

• For the Assess Only process, the Security Control Assessor - Organization (SCA-O) is responsible for performing the validation activities usually performed by the SCA-Validator (SCA-V). The SCA-O role is intended to be a title used by the Organization or Program Information System Security Manager (ISSM) or any other staff member supporting the AO that the AO chooses to delegate.
• IT being assessed will either have results recorded in an existing eMASS record a new Assess Only eMASS record.
• The security control baseline for Assess Only registrations is pre-defined based on the Application Security and Development STIG.
• For IT that does not fit into one of the pre-defined paths in the Assess Only process, the NETCOM Cybersecurity Directorate (CDS), as the designated SCA-Army, will triage the IT being considered for Assess Only.
• DISA IASE STIG Viewer assessment result checklist file (.CKL) or Continuous Monitoring Risk Scoring (.CMRS) will be used to import into the Assets module in eMASS. DISA's ACAS will be used for vulnerability scan results.
• The Information System Owner (ISO)/Program Manager (PM) will establish the relationships between the Assess Only registration(s) and authorized computing environment/enclaves (Assess and Authorize registrations). Any association, internal or external, requires evidence to support the documentation of inherited controls (this will happen automatically for internal associations; manual entries will be required for external associations).
• Fielding IT from any DoD approved program as a one-time deployment into an existing boundary does not require a new eMASS record. The eMASS record of the authorization boundary where the IT is being deployed (e.g. RNEC ICAN) will be utilized to record security control implementation and POA&M approval.
• Fielding a single hardware or software item into a one-time single deployment into an existing authorization boundary does not require a new eMASS record. The software must be assessed with named STIG (SRG not acceptable).
• Fielding IT from a DoD approved program as part of a managed solution or Program of Record (PoR) will require a new eMASS Assess Only registration, where the AO of the managed solution or PoR will be the approver. 
• Fielding a single hardware or software item into multiple authorization boundaries in which the single software item will be centrally managed will require a new eMASS record. The ISO/PM responsible for managing the single software item will maintain the eMASS record. 
• Any combination of hardware, software, or applications that are being fielded into an authorized computing environment can be approved via the Assess Only process and will require a new eMASS record.
• Platform IT requires a new eMASS record to support Assess Only approval.

Once the decision has been made whether to create a new eMASS record or use an existing eMASS record, the IT type is assessed as follows:

• ISO/PM identifies the applicable STIGs to be used to assess the IT type. The DISA SRG/STIG Applicability Guide and Collection Tool can be used. The ISO/PM lists the applicable STIGs in an Excel file and uploads them to the appropriate eMASS record.
• The ISO/PM reviews the security controls in Appendix C of the TTP as well as those security controls contained in the applicable STIGs. If any of the applicable security controls are not included in the initial security controls baseline, the ISO/PM will tailor in the additional security controls by updating the Implementation Plan in the eMASS record. The ISO/PM will ensure that any required overlays are tailored to the security controls baseline. The following security controls are listed in Appendix C:  AC (20), AT (1), AU (23) , CA (1), CM (13), CP (3), IA (23), MA (4), MP (1), PM (1), SA (7), SC (22), SI (9).
• The ISO/PM performs STIG assessment and uploads the results as a CMRF export (.XCCDF) and checklist (.CKL). The ISO/PM will also import the CMRS export files into the Asset Manager module of the eMASS record where the IT type is being deployed. The ISO/PM will ensure all failed STIG rules are mapped to applicable security controls and that non-compliant test results are created.
• When all test results are recorded, complete the second step of the Control Approval Chain (CAC). The SCA-O will review and validate all controls. 
• The SCA-O in conjunction with the Organizational ISSM will populate the Risk Assessment tap in eMASS, identifying the Vulnerability Summary and the Recommendations for vulnerability mitigation or remediation. The SCA-O can refer to the Security Control Assessor-Validator TTP, Appendix D, for assistance in calculating risk.
• The ISO/PM will create POA&M vulnerabilities for all non-compliant security controls. The ISO/PM will ensure that the POA&M Vulnerability Description matches the Vulnerability Summary from the Risk Assessment block.
• For IT being added to an existing eMASS record, the ISO/PM will create a POA&M Approval Package in eMASS. The Program ISSM will review the risk of any non-compliant security controls and compare that risk to the current approved residual risk level assigned to the authorization of the computing environment where the IT will be deployed. If the risk of accpeting the IT does not increase the risk of the authorized computing environment, the Program ISSM can approve i the AO role of eMASS. If the risk is increased, the AO must approve accepting the IT.

• For new Assess Only registrations in eMASS, the ISO/PM will create and submit an Assess Only Package for approval. The package will be routed through the Assess Only Package Approval Chain (PAC) for approval. 

DOD Instruction 5000.02, "Operation of the Defense Acquisition System", January 7, 2015, defines Mission Critical and Mission Essential:

Mission-Critical Information System. A system that meets the definitions of "information system" and "national security system" in the Clinger-Cohen Act (Subtitle III of title 40 of U.S. Code (Reference (p))), the loss of which would cause the stoppage of warfighter operations or direct mission support of warfighter operations. (The designation of mission critical will be made by a DoD Component head, a Combatant Commander, or their designee. A financial management IT system will be considered a mission-critical IT system as defined by the Under Secretary of Defense (Comptroller) (USD(C)).) A "Mission-Critical Information Technology System" has the same meaning as a "Mission-Critical Information System."

Mission-Essential Information System. A system that meets the definition of "information system" in 44 U.S.C. 3502 (Reference (aw)), that the acquiring DoD Component Head or designee determines is basic and necessary for the accomplishment of the organizational mission. (The designation of

mission-essential will be made by a DoD Component head, a Combatant Commander, or their designee. A financial management IT system will be considered a mission-essential IT system as defined by the USD(C).) A "Mission-Essential Information Technology System" has the same meaning as a "Mission-Essential Information System."

Mission Support are information systems that do not fall into either Mission Critical or Mission Essential.

The NETCOM Assess Only Tracker page is here:  https://army.deps.mil/NETCOM/sites/RMF/SitePages/Assess_Only_Tracker.aspx

The following paragraph concerns the old Army CoN process and is included here for historical record.

​In accordance with AR 25-1, paragraph 6-8, a Certificate of Networthiness (CoN) is required for all applications that are deployed on the Land Warrior Network, or LandWarNet (LWN). ​LWN is the Army's contribution to the global information grid (GIG), currently known as the DoD Information Network (DODIN), which consists of the globally interconnected, end-to-end set of Army information capabilities; associated processes; and personnel for collecting, processing, storing, disseminating, and managing information on demand to support Warfighters, policy makers, and support personnel. LWN includes all Army-owned, leased, and leveraged DoD, Joint communications and computing systems and services; software (including applications); data-security services; and other associated services (AR 25-2, paragraph 1-5c). The Army Network Enterprise Technology Command (NETCOM) manages CoN processing through the Networthiness SharePoint Portal.​ NETCOM, formerly a Direct Reporting Unit (DRU) to the Army CIO/G-6, is now a subordinate command to ARCYBER/2nd Army (effective 2014).

Many people ask whether they need a CoN or an Authority to Operate (ATO) (or both). The Army CIO/G-6 Cyber Directorate Office of Information Assurance or Accreditation (IACorA) has prepared the following guidance:  Application or Information System Determination: Definitions, Scenarios, Illustrations and Decision Tree, Version 1.1 23 January 2013. This 20-page document provides guidance necessary to make the distinction between application and system. Generally, if an application can be installed through "Add/Remove Programs" and has no server component, then it is an "application" (and thus only requires a CoN). There are scenerios (e.g. Scenerio 9) where an server can be categorized as an application if it a web service that is installed on an approved operating system and does not include other dedicated supporting servers or services. If the application is delivered as a solution (i.e. acts as a server, is delivered with an operating system, and/or opens up port(s) for unsolicited client communication, then it is a "system" (and thus requires an ATO). Under RMF, refer to DoDI 8510.01 or Define DoD Information Technology Type on the RMF Knowledge Service site. Sometimes the easiest way to make the determination is to apply for a CoN and see if it gets processed. All Information Systems ("systems"), which include Major Applications and Enclaves, as well as Platform IT (PIT) Systems must be assessed and authorized per DODI 8500.1 (see 9a, Figure 2) IAW DODI 8510.01 (was DIACAP, now RMF for DoD). Note that systems that are "type" accredited must be issued a CoN prior to deployment on LWN. This also applies to systems that are under development and have been approved for testing and granted an IATT - a Test CoN (T-CoN) is required also. For more details concerning CoN processing, see External SOP v0.9.
Per NETCOM's Memorandum "Certificate of Networthiness Expiration Dates" issued April 1, 2013, CoNs are valid for three years and are good for the major version of the application (i.e. if version 1.0 is approved, version 1.x is approved up to version 2.0). Depending on factors such as licensing agreements, functionality provided by the application, etc. a Limited CoN (LCoN) may be issued. LCoNs are not applicable Army-wide and you must fall into the scope of the LCoN to be allowed to use the application.
CoNs are more concerned with configuration management (keeping an application inventory for the Army, eliminating redundant applications, etc.) versus security. Other than looking out foreign ownership or control, there is little security analysis performed as part of the CoN process.
References:

• NETCOM Risk Management Framework Assessment Only Operational Tactics, Techniques, and Procedures, Version 1, April 2018
• NETCOM Memorandum, Subject:  "Certificate of Networthiness Expiration Dates, " 1 APR 2013
• Army CIO/G-6 Memorandum, Subject:  Employment of Collaboration Capabilities Procedures, 6 FEB 2008