Surviving the Invisible Commons

This article originally featured at the USNI Blog

In his piece, “Imminent Domain,” ADM Greenert suggests that the EM and Cyber spectrums need now be considered a stand-alone domain of conflict. Respectfully, we’re already there. The electronic environment, wired and unwired, is an obsession for defense planners. In CYBERCOM, the EM-Cyber spectrum practically has its own unified command. The navy’s component of CYBERCOM, the “10th Fleet,” in name harkens back to ADM Greenert’s example of the rise of sub-surface warfare. From the military’s fears over an assassin’s mace style EMP attack to the public’s obsession in movies like Live Free, Die Hard and games like Black Ops 2, the awareness is more than there. While we may have recognized this new environment, ADM Greenert is right in that we have not taken this challenge to heart.  If forces are going to operate as if the EM-Cyber spectrum is a domain of warfare, they must act as they would in the physical battlefield on the tactical level, not just the strategic: take cover, stay organized, and interrupt the enemy’s OODA loop.

 

TAKE COVER

 

In a battlefield, soldiers take cover to avoid detection and enemy fire. In the EM-cyber realm, we’ve made a habit of unnecessarily exposing ourselves to vulnerability. The US Navy has created an entire web of centralized databases that require not just mere control of the EM environment, but also a stability that often doesn’t exist at sea.

The Ordnance Information System-Retail (OIS-R) is the perfect example of unnecessary exposure to EM spectrum weakness. The system, designed to manage all ordnance administration, accounting, and inventory, requires a command to sign in to a shore-side database requiring uninterrupted connection through a Java interface. To access a ship’s ordnance data, one MUST have a functional internet connection either hard-wired or satellite. If account problems exist, troubleshooting must be done through other wireless means (phone, email, etc…) with land-based facilities. Each step requires a series of exposures to a very particular type of EM-Cyber connection to operate effectively.

The old system, Retail Ordnance Logistics Management System (ROLMS) was a stand-alone database that would update parallel shore-side databases through message traffic. The old system, while potentially harder for a single entity to manage, didn’t open the whole system to multiple weaknesses by environmental interference, enemy interference both kinetic and cyber, and equipment errors shore-side that a ship cannot trouble-shoot. It might be easier to keep all your ordnance (admin) in a huge pile, but to require warfighters to make a run through the open plains of TRON to get it is not a good idea.

 

STAY ORGANIZED

 

The drive to create centralized databases is often driven by a lack of organization on the part of the end-user. Properly organized supplies (data) minimize loss and the need to reach back into the logistical chain for material already packed. If the networks on ships are any indication, the average sailor enters the EM battlefield with absolutely no organization whatsoever. Sign in to a ship’s NIPR network and one will likely find  decade old files, repeated, in over a dozen similarly named folders: Operations Department, Ops, Operations, Ops Dept, OS1’s Folder, etc… Perhaps, those folders will have subfolders of the same name down 20 deep in series. Poor organization leads to inefficiency; inefficiency requires time, bandwidth, and exposure that should go towards the survival of the force and the success of operations. Ships need to treat their networks as they do their home desktops, organizing their material in a sensible way and deleting wrong, obsolete, or useless files.

Organization becomes the key to minimizing the need to go off-ship: well organized tech pubs, updated instructions in intuitive places, and personnel willing to spend the minute to search . A badly organized NIPR network is a reflection of how the navy treats the rest of its data: sloppily. We have seventeen sources pinging a ship for the same information that is held in 8 PowerPoint trackers, 2 messages, at least one call over the voice circuits, and 30 emails. Today, we expect every sailor to be at least an LS1 of the data-GSK, without giving them the tools or support to be so. One could drastically decrease the need to go off-ship for information by teaching sailors how to do a proper “ctrl-f” search or assigning an IT2 to deleting the ¾ of the network dedicated to obsolete files, animated .gifs, and 12 years of sea-and-anchor PowerPoints. Better training must exist not only in how to use data and of what kind, but how to properly disseminate/find it as well.

The battlefield equivalent of how we treat our data is sending soldiers into combat with a dozen different weapons from over the past century, but hiding them, their magazines, and their ammunition randomly throughout the base in mis-labeled boxes.  Like a poorly organized supply system, perceived “lost items” that are merely hidden end up wasting bandwidth on downloads, emails, and voice traffic as sailors work to solve the problems whose answers are merely in the 20th sub-folder down or in the inbox of the department head who doesn’t read his email. We must worry almost as much about the organization of our data as we do our organization of physical objects.

 

DOMINATE THE OODA LOOP

 

Survival often depends on an ability to use the enemy’s expectations of your methods against them. Some have suggested the navy embrace a wider range of bandwidths for communication; while true, more drastic measures are necessary to navigate the EM-cyber commons. In 2002, LtGen Paul Van Riper became famous for sinking the American fleet in a day during the Millennium Challenge exercise; he did so by veiling his intentions in a variety of wireless communications. We assume wireless to mean the transfer of data through the air via radio signals, but lights, hand signals, motorcycle couriers, and the like are all equally wireless.  These paleo-wireless concepts are just what we need for flexibility and security in the EM environment.

Combot vulnerabilities to wireless hacks are of particular concern to warfighters. Data connections to operators or potential connections between combots and ships serve as a way for enemies to detect, destroy, or even hijack our assets.  While autonomy is the first step in solving the vulnerability of operator connections, combots in the future must work as communicating teams. Fewer opportunities should be provided for subversion by cutting the long link back to the operator while maintaining the versatility of a small internally-communicating team. However, data communication between combots could still be vulnerable. Therefore, combots must learn from LtGen Van Riper and move to the wireless communications of the past. Just as ships at sea communicate by flags and lights when running silent or soldiers might whisper or motion to one another before breaching a doorway, combots can communicate via light, movement, or sound.

Unlike a tired Junior Officer of the Deck with a NATO code-book propped open, computers can almost instantly process simple data. If given the capability, a series of blinking lights, sounds, or even informative light data-transmissions  could allow combots of the future to coordinate their actions in the battlefield without significantly revealing their position. Combots would be able to detect and recognize the originator of signals, duly ignoring signals not coming from the combot group. With the speed and variation of their communications, compressed as allowed by their processing power, combots can move through the streets and skies with little more disruption than a cricket, lightening bug, or light breeze. High- and low-pitch sounds and infrared light would allow for communications undetectable to the average soldier or an enemy EW platform.

One must also accelerate faster than the enemy’s OODA loop can process. In the cyber realm, the enemy is often software long-ago released by its human creators. Like the missile warfare that inspired AEGIS, cyber warfare is both too vast and too fast for human reaction. Capital investment would concentrate more money in autonomous and innovative defensive programs: 10th Fleet’s AEGIS. Proactive patrol and detection can be done with greater advancements in adaptive self-modifying programs; programs that can learn or understand context are far more appropriate.  Recent developments in computing systems point to organic systems that could “live” in the systems they defend. Biological processors and organic computing allow for hardware that thinks and learns independently, potentially giving defensive networks the added advantage of an instinct and suspicion. Imagine the vast new horizons in the OODA loop of defensive cyber systems with hubs sporting the defensive animal instinct and the ability to re-wire their own hardwareQuantum computing also hovers over the horizon, with not only vast consequences for computing speed, but he whole cryptological offense-defense equation. The image painted is dramatic and far-off, but modest investment and staged introduction would serve as a better model than the dangerous possibility of a “human wave” mode of thinking. With fluid cyber-defense systems guarding more disciplined communicators, the US Navy can crush ambushes in the invisible commons.

 

ACTING LIKE IT

 

We will never be able to completely control the invisible commons; it is too heavily populated and easily influenced. Those conflicts held within vision are often confusing enough; the invisible becomes infinitely harder to master. However, if we minimize unnecessary exposure, organize ourselves well, and move with aggressive speed and unpredictability, our convoys of data will survive their long mili-second journey across the EM-cyber sea. ADM Greenert is right in saying the EM-Cyber world is a new field upon which battle must be done. However, while we may have realized it, we must start acting like it.

Matt Hipple is a surface warfare officer in the U.S. Navy.  The opinions and views expressed in this post are his alone and are presented in his personal capacity.  They do not necessarily represent the views of U.S. Department of Defense or the U.S. Navy, although he wishes they did.

 

3 thoughts on “Surviving the Invisible Commons”

  1. Lack of organization on the part of the end user will be a recurring theme until the development of automating AI (Artificial Intelligence) based systems that can “learn” to recognize and prioritize (say with respect to the latest version of Commander’s Critical Information Requirements, or CCIR) the voice and electronic media communicated or otherwise generated by war-fighters in their duties. -then automate consistent “warehousing” of this data for automated search, retrieval, and reporting purposes.
    Taking war-fighters off of assigned maintenance, operational, or training tasks to sift through, and make sense of data detritus that has accumulated over significant periods of time will be ever more challenging in a resource constrained environment.

    1. It’s easiest for organization to be done by the people using the database. If you put “Rev 8″ of a document on a drive, why should Rev 1-7 have multiple copies all over? Shouldn’t you delete them as you add the new instruction? The idea isn’t to take warfighters away from their duties, but have them conduct their duties in an organized manner. When a GM does maintenance on a gun, he doesn’t just throw the bullets all over the armory as he’s doing it. We’ve shown a greater obsession with sailors making their racks properly and shining their boots than if they can get the information they need to do their job in a secure and sensible manner. Of course, at one point someone will have to go through, but that could be as easy as sending out a mass “instruction” file to be loaded onto every platform and giving everyone a week to designate what they want to keep before everything else is deleted.

      As for comms, if people KNOW where the information is that you sent them the first time, will 20 different parties chat, email, and do voice call-ups for that information?

      All that said, I like the idea of a virtual call-center operator, although it potentially adds another layer of em-cyber weakness in requiring yet another system for communication to occur. It would be like an OIS of comms.

Leave a Reply