As a global command, NETCOM makes itself the network proving ground

MG Jennifer Napper has been the commanding general of Army Network Enterprise Technology Command (NETCOM) for just under two years, and in mid-August will take over her new assignment as director of plans and policy (J-5) for U.S. Cyber Command, Fort Meade, Md.

Replacing Napper as commanding general at NETCOM is MG Alan Lynn, who has been the Army’s Chief of Signal for the last two years.

Napper spoke with Defense Systems Editor-in-Chief Barry Rosenberg just before her reassignment to discuss the major challenges facing military networks.

DS: With enterprise email, what’s the end game? Is it just about migrating x-millions of users? What comes next?

Napper: If you think about how industry looks at which things should be local and which things should be at an enterprise level then you can see where we were going. For instance, I am a global command, and there are some capabilities that if you put inside my domain of CONUS I can’t use in the Pacific for my other commands—one of those being collaboration capabilities. So we are engaging in a pilot [program] right now to put some collaboration capabilities in the enterprise or the cloud, so to speak, such as documents and workflow that will allow me to function globally so that the people in Europe or the Pacific or Southwest Asia can post documents to us.

DS: So you’re presently sharing documents through a cloud?

Napper: Correct, so it’s on my portal now, and all the subordinate commands can look at it the same time. It shows up on my portal a week before meetings, and addresses documents that need action or anything that needs to be signed off.

We are having some challenges right now with some of the technology, so we not ready to open that to everybody just yet. But we like to use our command as the pilot, because it is a global command, and because if it’s going to be bad I rather it be bad for my command so we can work through the technical issues or decide that it’s not the way we want to go—and that’s important.

DS: NETCOM is tasked with taking over operational control over all Army networks. What does that entail?

Napper: Operational control means enforcing standards, providing direction on configurations and giving authoritative direction necessary to accomplish the mission. In this case that mission is to build, operate and defend the network.

DS: Is operational control something you could take over tomorrow, like flipping a switch? What does it entail?

Napper: For those disparate stovepipe functional networks today there’s some coordination and synchronization work we have to do. I think it will take somewhere between three and four months to do it correctly, and phase in different commands at different times based upon how ready they are.

DS: The military spends a lot of time improving situational awareness for troops on the ground. How do you improve situational awareness for networks?

Napper: In any operational domain the first thing you do is learn how to see yourself and see who else is in the domain; we call it situational awareness, from which you then can draw some form of situational understanding. In this domain called cyber, where our networks built up the way they did (over time), we really cannot see everything that’s on the network. So we’re focusing this year and into next year on something called IT Asset Management.

We’ll look at the different pieces and parts of hardware and software currently running on our network, and consolidate that view so that we can understand everything that we’ve put on the network. That will allow us to start to build that situational understanding of what’s on the network, how it’s functioning and is it functioning like it’s supposed to.

We have pieces of parts of this at posts, camps and stations. I could have told you about everything on Fort Huachuca’s network, for example, but you probably couldn’t see it if you were off Fort Huachuca. If there is activity in Fort Huachuca’s network that we aren’t being told about, then we may not be able to correlate that with activity on Fort Bliss’s network

Unless you have visibility all the way across the enterprise then you can’t begin to collate events and decide whether or not you have a systemic problem or if you have malicious software in your network or another problem. So our big focus this year is continuing to develop that capability.

DS: What tools do you use to get that visibility into these networks and tie together the stovepipes?

Napper: I cheated and didn’t buy any tools. What I did is say, ‘tell me all the tools you have on your network and what kind of information that they already produce.’ When you buy a router it comes with software that tells you the current status of your router, but where is it reporting to…probably nowhere very high (up the network).

And so what we do differently is put connectors on the network and pull that data out that you already have so that we can correlate it. You find out some interesting things when you do that. When I put a router on the network at Fort Huachuca, for instance, I may have named it Router One, Building Two. But I may have a router on the network at Fort Bliss that is also named Router One, Building Two. So we don’t have (the necessary) standards when naming devices, and the second phase of this is to go back and clean up the data.

DS: And that naming issue can happen 50 times over with dozens of different pieces of hardware.

Napper: Correct. My last update of what percentage of the network that we are seeing…since we’re getting pretty healthy…I would say it’s better than 70 percent of the network today globally, and we have over four million different devices to look at.

DS: What have you learned about the network that you didn’t know two years ago when you became NETCOM commander?

Napper: There is no aspect of our operations today that we can’t improve by using the network more effectively. It doesn’t matter if we are talking about pay or taking about ordering bullets down range. There is no aspect of operations that the network cannot enable and do better. My concern with that is the one thing we can’t do with the network is to prevent human error.

From my perspective we have a network-enabled Army, and that means soldiers at every level are all on the network. And soldiers make mistakes, they’re human, the same as civilians, so we need to focus on affecting the least amount of the network when humans make mistakes.

Reader Comments

Wed, Aug 8, 2012 Alice-Sofia the US

Concerning: “We’ll look at the different pieces and parts … how it’s functioning … we don’t have (the necessary) standards when naming devices… go back and clean up the data.” 1/ Looks like the control center of the net has no knowledge of the net’s components and data they transfer. Inferences: there is no system vision; there is a possibility of enemy’s devices already functioning within the net. Consequences: failure to achieve the purposes of the net, firstly, secure communications. If the army has no reliable communications, “national security” is just words. 2/ The simplest code is hierarchical description of the systems and its subsystems. For instance: Central Command, division #1, subordinate X, second terminal, five components in possession of terminal operator, mouse is fifth component. If devices codes start with 0 – common for the Central Command, then device code (mouse) is 0.1.X.2.5….. Then, each subnet could have ID number after 0, with continent/regional/etc codes, and so on. For instance this Fort Huachuca is one of 2500 subnets within the US; its code might be 15.2500.3.5.6…. that means: 15 – location within the US, 2500 – ID number of Fort’s subnet, 3 – division, 5 – terminal’s code, etc. In theory, the net should be coded and assembled by the Center and have special Managing Core/Node; otherwise, it is just collection of hard/soft pieces that do not work for secure achievement of the purposes. If the purpose is to create the secure net from the existing insecure stuff, decide the purposes first, design structure, command lines, data contents and traffic, communication links, assign codes, decide responsibilities for maintenance and control; then, take inventory, decide what else is needed, and so on. So, there will be no possibility for “Napper: I cheated and didn’t buy any tools.” And only the device that serves purposes should be a part/subsystem of the net – known, controlled, achieving the purpose. Concerning: “Napper: Correct. My last update… over four million different devices to look at.” The net of such a volume should be designed as auto–controlling net: each device should be identified and controlled through special hardware–software modules that allow the devices to be a part of subnet and to access other subnets within the net. Then, it would be possible “to see the net” as mapped verified purpose–oriented system of communications. Concerning “we have a network-enabled Army… humans make mistakes.” The main mistake already has been made: there is no net under control, if there is no knowledge of each component (mainly how it works for the purposes of the entire net). I would suggest training in systems theory, in particular, design of systems for achievement of purposes. Personally, I hope that this article is disinformation ops, not reality! Respectfully, Alice–Sofia

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above