Today's ever-changing battlefield and rapid advances in technology call for systems that are more intelligent, independent and robust than ever. From robotics and manned-unmanned teaming to artificial intelligence to cyber and electromagnetic warfare, it is vital that the Army acquisition process effectively deliver technologically sophisticated systems to meet the threat. Equally important, however, is an acquisition workforce that is fully aware of how to develop these systems for success--for example, by applying the necessary cyber protections and understanding the system's complexities before testing and training, and then providing the right training to the Soldier-user.
The Acquisition Lessons Learned Portal (ALLP) gives the Army acquisition community a forum to share lessons on how, specifically, to deliver successful systems and what pitfalls to avoid. The following lessons learned reflect the experiences and knowledge of project management office (PMO) staff and other acquisition stakeholders in unmanned systems and cybersecurity.
TRAINING FOR UNMANNED SYSTEMS
LL_241: AS SYSTEMS BECOME MORE COMPLEX AND INTERFACE WITH OTHER SYSTEMS, TRAINING IS CRITICAL TO FULLY AND EFFECTIVELY EMPLOY THE SYSTEM ON THE BATTLEFIELD.
BACKGROUND
The initial operational test and evaluation operators for one unmanned aircraft system (UAS) received general training on the system, but the training did not specify certain key aspects of effectively employing the system in executing the mission, such as how to conduct reconnaissance properly. Additionally, the training omitted how to interface with the ground unit the operators were supporting--that is, how to communicate what the UAS was seeing to someone on the ground.
These training deficits, all of which were avoidable, had a measurable effect on mission success and made it harder to demonstrate hardware capabilities at a high operational tempo (OPTEMPO).
RECOMMENDATION
Establish clearly in advance the types and levels of experience that Soldier participants will need to fully employ the system in testing and evaluation, such as missile range certification, radio communications and fundamentals of reconnaissance.
LL_233: USE OF ILL-PREPARED TEST PARTICIPANTS AND IMMATURE SYSTEMS CAN ADVERSELY AFFECT TEST RESULTS AND CONCLUSIONS.
BACKGROUND
Trainee operators of an ancillary developmental system were ill-prepared under most circumstances to demonstrate tactically realistic interaction as a part of a system of systems. The operators did not communicate and interact effectively with other parts of the maneuver force, at times hindering the manned-unmanned teaming being demonstrated. Specifically, they often were unable to cooperatively perform surveillance, target detection, target acquisition and engagement, which unfairly biased the test results by suggesting inadequacies in the primary system under test. Only expert analysis made it clear that the results were an anomaly.
High OPTEMPO for operational units and scarcity of resources often create competing testing priorities. In such cases, it is necessary to determine the best possible alternative in terms of available tactical units and equipment.
RECOMMENDATION
Insist on using only test participants that are at readiness level 1 or fully mission-qualified in their respective roles, to obtain the most accurate and unbiased test results.
LL_838: THE INTEGRATION OF A PARTICULAR SENSOR ON A UAS POSED UNIQUE TRAINING CHALLENGES. ROLES AND RESPONSIBILITIES MUST BE CLEARLY DEFINED BETWEEN PROJECT MANAGERS (PMS) TO AVOID SUCH CHALLENGES.
BACKGROUND
The acquisition strategy for the sensor specified that the training would be the responsibility of the platform PM with close support from the payload PM. The training strategy for the sensor consisted of UAS training packages provided by the payload PM for integration into new equipment training (NET) and institutional training center curriculum.
Over a year, the sensor team observed a decrease in the tactical use of the sensor. After-action reports from fielded units confirmed a limited understanding of how to operate the radar. This was a reflection of the limited sensor training provided to the payload operator--three hours of instruction in the UAS NET.
The sensor team that provided contractor training support to the UAS NET events had encountered difficulty getting dedicated resources, such as flight time, to conduct sensor training. The team observed that radar training for UAS operators was a lower priority than training for other aspects of operating the UAS and therefore was assigned a smaller window of opportunity, which poor weather could narrow further.
This training deficit at the UAS operator course for Military Occupational Specialty 15W (unmanned aircraft systems operator) stemmed in part from an improper categorization of sensor system training tasks. The Army included them in the 2000 series; that meant they were taught exclusively through presentations in the academic setting of advanced individual training (AIT), where Soldiers received just an overview of the sensor instead of hands-on instruction in operating or commanding the payload in a realistic environment.
RECOMMENDATION
The payload PM needs to assert more emphasis on training rather than allowing the platform PM to direct sensor training activities. In particular, the payload PM should:
-- Continue to use embedded trainers to support NET activities.
-- Work with the platform PM to get dedicated sensor training time during NET.
-- Work with the platform PM to increase the number of hours of sensor training conducted during fielding and possibly expand the current training curriculum.
-- Investigate and address current simulator shortfalls with the Program Executive Office for Simulation, Training and Instrumentation and all stakeholders, as incorporating the radar simulator may improve training.
-- Engage all stakeholders to address re-categorizing sensor training tasks to series 1000 tasks, to enhance the Soldiers' sensor training experience in AIT.
CYBERSECURITY
LL_540: INSTITUTE BASELINE CYBERSECURITY REQUIREMENTS AS A CONDITION OF CONTRACT AWARD FOR APPROPRIATE ACQUISITIONS.
BACKGROUND
Baseline cybersecurity refers to first-level information and security measures used to deter unauthorized disclosure, loss or compromise of information. Basic protections, such as updated virus protection, multiple-factor logical access, methods to ensure data confidentiality and current security software patches, are broadly accepted across the government and the private sector as ways to reduce a significant percentage of cyber risks. Ensuring that the people, processes and technology with access to at-risk assets are employing baseline requirements raises the level of cybersecurity across the federal enterprise.
Often, cybersecurity requirements are expressed in terms of compliance with broadly stated standards and are in a section of the contract that is not part of the technical description of the product or service. Doing so leaves too much ambiguity as to which cybersecurity measures are actually required in the delivered item.
RECOMMENDATION
For acquisitions that present cyber risks, the government should do business only with organizations that meet such baseline requirements in both their own operations and in the products and services they deliver.
The government should express the baseline in the technical requirements for the acquisition, and should include performance measures to ensure that the contractor maintains the baseline and identifies risks throughout the lifespan of the product or service acquired.
Because of resource constraints and the varying risk profiles of federal acquisitions, the government should take an incremental, risk-based approach to increasing cybersecurity requirements in its contracts beyond the baseline. As a preliminary matter, cybersecurity requirements need to be clearly and specifically articulated within the requirements of the contract. First-level protective measures are typically employed as part of the routine course of doing business. The cost of not using basic cybersecurity measures would be a significant detriment to contractor and federal business operations, resulting in reduced system performance and the potential loss of valuable information.
LL_742: PER ARMY REGULATION (AR) 25-2, INFORMATION ASSURANCE (IA) CERTIFICATION IS A REQUIREMENT FOR INFORMATION SYSTEMS SEEKING TO NETWORK IN ARMY ACTIVITIES. PROGRAMS NEED TO DEVELOP IA STRATEGIES VERY EARLY DURING THE DESIGN PROCESS TO AVOID COST AND SCHEDULE IMPACTS.
BACKGROUND
During the requirements development phase and subsequent build of one electronic warfare system, the developer did not address IA. Consequently, an IA assessment performed after the system was developed determined that the system's security posture did not meet Army IA regulations or National Security Agency (NSA) requirements. Had an IA subject matter expert (SME) engaged with the developer from the start, the SME would have determined that the operating system (OS) and the hardware and processor being developed and integrated into the system were not on the NSA pre-approved list and lacked a validated encryption algorithm.
Not using the NSA pre-approved OS or hardware does not mean a certification cannot be obtained; however, it does mean that NSA must evaluate and certify the system, which adds a significant amount of time to the schedule. In addition, NSA findings could require that the system undergo re-engineering efforts to correct any encryption or OS security issues. This effort could result in invasive hardware changes or simple software modifications.
Consequently, the PMO expected the program to experience schedule delays, adding high risk to meeting program objectives. The PMO estimated that it would take 6-10 months to do initial scans on the system and get chief information officer/G-6 validation. Getting into and through the NSA certification process with no issues could take up to 12 months, while any fixes required to achieve certification could add time to the schedule to implement and test. The original equipment manufacturer estimated that it could take 18-24 months to implement a hardware change. The system would then have to be re-evaluated, which could add another 6-12 months.
RECOMMENDATION
As soon as a networking requirement is determined for the system, IA and cybersecurity SMEs need to be active members of the design and development team. The IA SME will incorporate AR 25-2 requirements into the system design strategy and assist the program with determining the timeline for certification and accreditation (C&A) efforts for planning program objectives. Validating IA controls (per DOD Instruction 8500.2) during the system development phase benefits the program by eliminating re-engineering efforts, allowing C&A efforts to be successfully completed while meeting timeline objectives.
When using communication security (COMSEC) material, engage PMO network enablers (PMO Net E) in the initial development stages as directed by the assistant secretary of the Army for acquisition, logistics and technology to ensure that COMSEC methods are NSA-approved. PMO Net E are the designated technical experts and offer COMSEC-approved devices at no cost. Using technology that is not COMSEC-approved will require NSA certification, which could be a lengthy process and pose a high risk to program objectives if NSA-approved techniques are not used.
For more information on these and other Army Lessons Learned within the ALLP.
This article will be published in the April - June 2017 issue of Army AL&T Magazine.
Related Links:
U.S. Army Acquisition Support Center
Social Sharing