Turning Shadow to Light: Empowering Grassroots Navy Software Development

Turning Shadow to Light: Empowering Grassroots Navy Software Development

By LCDR Cory Poudrier, USN

Throughoutthe Naval Aviation Enterprise (NAE), aviation units use the Joint Mission Planning System (JMPS) to push platform data to their aircraft. This system allows operators to mission plan with dissimilar units, access shared network resources, and do much of their tactical decision making ahead of launch times. Because this system is shared by so many entities, it has attempted to take a one-sizefits-all approach. The backdrop of the software is common, but each type/model/series (T/M/S) aircraft has their own platform specific version of JMPS that includes the intricacies of each. For example, the MH-60S and the MH-60R share a lot of planning interface software, but the MH-60R has unique tabs for electronic warfare and anti-submarine warfare mission sets. Currently, the assets and structure of this program, to include a lot of network storage, is administered and managed at the local level by a single trained user. This being a Navy program, turnover occurs every 6-12 months. Consequently, the lessons identified and learned by the off going JMPS Officer are forgotten or misunderstood, the tools they develop to make their jobs easier break, and the program falls in and out of fashion as tech savvy lieutenants come and go. This program, specifically in HSM, has seen a great deal of innovation from a personal investment standpoint, encompassing batch files that automatically map share drives and user folders, startup functions that maintain a clean system, or even well-developed programs like Launchpad, designed to make the JMPS Officer’s job and collaborative mission planning easier. Sadly, all these solutions exist only at the squadron level, and unless shared or stolen by interested JMPS oOfficers, often sit in obscurity after those individuals leave. These programs and tools are examples of “Shadow Information Technology (IT),” programs created by users that are not controlled or authorized by the IT Department.

As the Department of Defense pivots to focus on the Great Power Competition (GPC) mindset, we have focused an incredible amount of effort on reevaluating the way we operate in a multitude of battlespaces. The nature of this competition is defined by the ability to adapt and reattack at speed, on all fronts, from the seabed to space. The idea of outpacing enemy adaptation is not new. John Boyd’s Observe, Orient, Decide, Act (OODA) Loop dates back to the Korean War. This concept, especially within the Naval Aviation Enterprise, is pivotal in the digital battlespace. The impact of cyber effects and wins and losses within that space will ripple out into all other aspects of the fight. Should the U.S. Navy fail to understand and adapt to modernized software development strategy, they could very well lose the fight before it has begun. There is a need for the Navy to be able to adapt and support small scale change at the fighting edge, a current weakness defined by their lack of control in Shadow IT. The innovative spirit of Sailors is unquenchable, and their desire to continuously improve the systems that they work with will either generate an incredible attack surface for cyber threat, or empower a shift in dynamic that will give the NAE a competitive edge in this new era of warfare.

Cyber warfare is by its very nature agile. Changes in attack vectors and surfaces occur at the speed of updates, and redundant and integrated systems are designed to reduce the ability of bad actors to infiltrate and impact critical components. While new systems are, in accordance with the National Institute of Standards and Technology Special Publication 800-53, addressed for their security controls, old IT systems or unauthorized development are difficult to backdate to current standards. Considering the age of the NAE’s platforms and associated support systems, this problem set is massive. The Navy operates over 3,800 aircraft of various types, models, and series, and each has a unique capability and sensor set that feeds the Naval Aviation mission. With those unique capabilities come unique risks: an airborne radar poses different software concerns than a jammer, and a drone presents different issues than a manned platform. The need from operators for rapid change, and the rapid tools developed by those operators are essential to cover capability and risk gaps that could take years to resolve through traditional acquisition models. These solutions are often referred to as Shadow IT. Shadow IT is defined by its gray area nature. Developers of various skills use code from varying sources to build tools that address hyper-local needs. Some examples of this are python scripts to scrape spreadsheets, mission planning programs that map drive locations consistently, or even applications that poll Navy websites for information. These tools are no doubt useful, and this problem is not exclusive to the DOD. Because these programs are built on such a small scale, users are exploiting gaps in policy or security infrastructure to use them. It is not uncommon to see a tool built on a home computer pulled into the DOD infrastructure because it can be executed, but not built within the Navy Marine Corps Intranet (NMCI)

Rather than go on a flaming sword crusade to burn all this innovation from our systems in the name of security, the DOD should seek to encourage, screen, and secure these applications. This is not a simple task. The sheer volume of individual systems that the Navy alone employs is enormous. There are maintenance systems, and systems adjacent to that system that feed into the larger infrastructure. There are mission planning systems that share a common user interface but exist in both unclassified and classified formats, often shared amongst multiple type/model/series (T/M/S) of aircraft. There are nearly countless varieties of personnel support systems (NSIPS, FLTMPS, BUPERS Online, to name a few), each with unique password requirements and authentication methods. While each of these appear separate, they all meet at one common point: the operator. Operators will continue to seek solutions that align and increase the efficiency of this web of systems, and they should be encouraged to do so. They should be provided the training, tools, and infrastructure that support doing it correctly with an eye towards innovation and security, and they should be rewarded for this innovation by allowing them to build on this culture of change.

The Defense Innovation Board (DIB) Software Acquisition and Practices (SWAP) Report specifically calls out two lines of effort that can be leveraged to take advantage of Shadow IT. These are creating and maintaining cross-program/crossservice digital infrastructure and creating new paths for digital talent. The DIB SWAP Report focuses on the DOD, creating the framework for digital infrastructure at the leading edge (the operational level) of the cyber battlespace, allowing small, incremental changes to be appropriately developed and simultaneously identifies digital talent. I would propose that the infrastructure and talent management models combined take a hub and spoke approach.

In the case of the infrastructure, the hubs would be maintained by type wings. I’ll highlight changes with the Helicopter Maritime Strike (HSM) Community as an example. HSM Wing Pacific, as an example, controls 11 squadrons in 3 geographic locations that deploy from carriers, destroyers, cruisers, littoral combat ships, and amphibious landing ships. Each of those squadrons operate in a unique environment, and interact with countless naval systems along the way. Users are developing tools for those purposes at each squadron, but often in silos, and often on local machines with low processing power and no security backdrop. Rather than continue this approach, HSM Wing Pacific would serve as a software playground surrounding a factory, providing free to use (to the operator) tools and databases on both NIPR and SIPR to develop new programs and tools. These tools would include containerized development environments, analytical tools, and cloud-based computing assets, hosted at the wing level, that will signal boost any minor developments that individual users can achieve. Platform One serves as a great example of what is desired–cloud based development apps, anchored in DevSecOps structure, and CAC enabled to control access. Because this service is cloud based, hosts for software factories can screen code for vulnerabilities and maintain a repository of source code for future development. The drawback to Platform One is cost. Commands need to justify their need statement through heavy paperwork drills that most operators don’t have the time or knowledge to undertake. Friction of this nature will only encourage operators to continue in the shadow realm. Going back to the JMPS example: there has been, for a number of years, an opportunity to bring JMPS onto NMCI networks to support collaborative mission planning. Most JMPS Officers view this as not ideal. The broad scope that JMPS Officers have to build useful tools and administratively control their system suffers. So rather than move systems over to big Navy networks, it is easier and desired to keep JMPS offline. Development under this model needs to be easy and rewarding to encourage its use. Additionally, good products developed in the cloud can be rapidly deployed to other units within that type wing, through internet or regular mission planning system updates, amplifying the effects of smallscale development. The spokes then become the individuals writing code. Amateur, and sometimes professional, analysts and developers would be able to reach to the wing hosted hubs for mentorship, quality assurance, and source code that may speed their time to field, similar in a lot of ways to the tactical development model employed by Naval Aviation Warfighting Development Center. As these spokes become more numerous, the hubs will need higher level support to screen their applications, and this higher spoke can then reside with the TYCOM at Naval Air Forces, sharing tools, code, and knowledge in much the same way as the type wings.

Talent management in this model would be managed external to traditional methods and will likely require creative billeting and changes to the current personnel model. Some innovators are prolific, while some are one trick ponies. The staff would need to evaluate and screen the software it sees from individuals that stand out, preferably based on rate of development and quality of work, to staff wing level positions. These wing level positions could then be evaluated among their peers to feed the TYCOM positions that will continue to build this infrastructure from the outside in, building contracts with DOD-wide assets to continue to share code and define the process by which low-effort software is developed and used. Initially, these billets would be filled with already existing wing staff 1310 lieutenant positions, possibly one at a time. Those lieutenants, now charged with identifying talent, can absorb temporary duty personnel of interest to expand the wing work capacity. With these talented individuals, it is important to define their skillset. A data analyst is a very different creature than a programmer, and the Navy should adopt Navy Enlisted Classification and Additional Qualification Designation definitions that keep Sailors within their talent pool. This will then inform greater resolution within the structure, pooling talent where it is needed most and allowing for a talent marketplace with more billet maneuverability. By standardizing these NEC and AQD definitions, the Navy can send these individuals through higher level schooling to boost their skillset and value to the organization. Once these individuals have proven themselves to be good managers of digital talent, they are then pulled into acquisitions billets to tailor acquisitions policy to feed this system, writing policy in a manner that encourages this model throughout all services.

OODA Loop

Finally, as this talent and infrastructure begins to take shape, the NAE can use this model to enact DevSecOps methodology for wider release. In this case, software is developed at a squadron on wing tools, on the wing cloud, ensuring that approved tools and containers are used to design and test these solutions. Once tested, the wing software factory can put code through additional screening to ensure that it meets DOD wide requirements, to verify that use will not harm the greater software ecosystem, and then deploy particularly useful software to users via cloud or asynchronous updates.

LT Karl Kobberstand from Helicopter Maritime Strike Squadron (HSM-37), flies a virtual MH-60 helicopter as Naval Aircrewman (Tactical Helicopter) 3rd Class David Finley defends against virtual enemy combatants during an Office of Naval Research (ONR) demonstration of new and improved training which combines software and gaming technology to help naval forces develop strategies for diverse missions and operations. U.S. Navy photo by John F. Williams.

By encouraging this open environment for development, security can also be screened at the squadron end on receipt by interested users, providing bug reporting and vulnerability testing through a GitHub open-source model. Finally, this code is retained and updated at the wing level for updates to systems, allowing wing hubs in coordination with program offices to rapidly identify upcoming changes to fielded systems that may impact these tools. They can then inform users of these changes to encourage operational level problem solving motivated by the impending loss of a useful tool. Part of this process described above can be absorbed by the already existing Black Pearl family of continuous authority to operate tools already in place on Platform One

.

By decoupling low level software development from major acquisitions efforts, improvements can be made that are more specific to the operational environment. In much the same way that operational test serves to validate systems, relying on a hub and spoke software factory, further down the line of accounting, identifies risk and requirements that would likely go unnoticed at upper echelons. It also enables the most critical factor, speed. Normal waterfall software development, and changes to that product once production has begun, are not known for rapid integration and deployment. The primary concern with any software development strategy in the Government Purchase Card construct needs to be the speed at which it can take effect. Failure to address issues at the point of impact, be they programming bugs or unintended impacts, will cripple the affected unit until a solution is found, developed, and integrated. Type wings are uniquely situated to assess these problems and push out solutions to the places where they matter the most. The tight command relationship between a wing and squadron necessitates near constant communication, Continuous Integration/ Continuous Delivery (CI/CD) strategies stress the importance of constant feedback to ensure products are meeting the needs of customers. They are also uniquely placed to identify larger patterns of problems within this model. They sit higher than the operational environment and can view the wider scope of problems thus informing tool development that meets a wider need when it is appropriate while controlling for the risks that can arise from nonstandard or poorly written tools. Additionally, the efforts of standardizing tool sets allows wing software factories to distribute code to other T/M/S to aid in solving problems collaboratively. By enforcing DODI standards, these tools can easily be adapted to entities outside of the NAE. It isn’t difficult to imagine that a destroyer or submarine squadron could fill this same need for the ships and submarines under their purview, feeding their chains of command data in a wide web of user driven, Navy screened software development.

Even if the Navy decides to choose a traditional, top-down route to address the issue of Shadow IT, they will inevitably face the fact that the innovative spirit of Sailors will not be quelled. The U.S Navy’s abilities in the next conflict will be defined by how we spend that capital.

Talent management in this model would be managed external to traditional methods and will likely require creative billeting and changes to the current personnel model. Some innovators are prolific, while some are one trick ponies. The staff would need to evaluate and screen the software it sees from individuals that stand out, preferably based on rate of development and quality of work, to staff wing level positions. These wing level positions could then be evaluated among their peers to feed the TYCOM positions that will continue to build this infrastructure from the outside in, building contracts with DOD-wide assets to continue to share code and define the process by which low-effort software is developed and used. Initially, these billets would be filled with already existing wing staff 1310 lieutenant positions, possibly one at a time. Those lieutenants, now charged with identifying talent, can absorb temporary duty personnel of interest to expand the wing work capacity. With these talented individuals, it is important to define their skillset. A data analyst is a very different creature than a programmer, and the Navy should adopt Navy Enlisted Classification and Additional Qualification Designation definitions that keep Sailors within their talent pool. This will then inform greater resolution within the structure, pooling talent where it is needed most and allowing for a talent marketplace with more billet maneuverability. By standardizing these NEC and AQD definitions, the Navy can send these individuals through higher level schooling to boost their skillset and value to the organization. Once these individuals have proven themselves to be good managers of digital talent, they are then pulled into acquisitions billets to tailor acquisitions policy to feed this system, writing policy in a manner that encourages this model throughout all services.