NASA OIG: GSFC Increased Vulnerability of Near Earth Network
NASA OIG: NASA’s Management of the Near Earth Network
“By deviating from elements of Federal and Agency cyber and physical security risk management policies, NASA, Goddard Space Flight Center (Goddard), and the Near Earth Network Project Office increased the Network’s susceptibility to compromise. Specifically, NASA assigned a security categorization rating of “Moderate” to the Network’s IT systems and did not include the Network in its Critical Infrastructure Protection Program. We believe this categorization was based on flawed justifications and the Network’s exclusion from the Protection Program resulted from a lack of coordination between Network stakeholders. Given the importance of the Network to the success of NASA Earth science missions, the launch and contingency support it provides for Federal partners, and its importance in supporting human space flight in the future, we believe a higher categorization and inclusion in the Protection Program is warranted.”
What is the benefit of centralizing NASA’s IT needs? Doesn’t this centralization lead to a single point of failure?
What’s so special about NASA’s IT needs that those needs can’t be met with COTS banking (or similar) software? OK, there’s all sorts of restrictions, especially offshore, but still.
(I’ve actually wondered though about the integrity of data from far-flog probes and why it hasn’t been compromised by some smartass script kiddies. Imagine for example hijacking the feed from, say, Pioneer 10, hijacking the stream so that it “shows” alien life in deep space?).
If it’s custom software, I can see an advantage in all the centers using the same vendor, customer support, etc. That would open the door for a single point failure due to common bugs, but it would be more efficient. I don’t think the issue is common hardware or networks, because those don’t, for the most part, exist. Getting inside the firewall around the JPL flight ops network doesn’t get you inside the firewall to GSFC’s similar network.
Why do they use custom software rather than COTS? I’ve never heard a good reason (at least not one I consider good.) I once was involved in a debate with a software development manager at JPL, who insisted that every bit of software needed by a particular mission had to be developed according to formal development process for class A mission software. He was dead set against reusing anything existing code, since it hadn’t been developed by writing down requirements for the current mission, reviewing them, writing ICDs, etc. Anything else, he called “incompetent software management.” I was not convinced.
I also have the cynical view, which also applies to physical security at nonclassified sites, that senior managers just like it. If by insisting they need custom software, high security, etc., even when they don’t, they are implicitly arguing that they are extra special and important. That is good for their institution’s image.
As far as hijacking the feed from a spacecraft, that would be hard. Not impossible, but hard and easy to catch. You couldn’t fake the signals to the DSN antennas without having a spacecraft along the line-of-sight. I think the path from the DSN to JPL is isolated. From JPL, the pipe branches, so anything downstream of that would only distribute the forgery to some, but not all, recipients. The only place I could see it happening is the mass storage inside JPL. Not impossible, but difficult and even if someone did it, that’s the data at a very raw level. Someone would have to know exactly what the bit stream coming out of an instrument looked like. CCSDS header, packetization, checksums, instrument-internal inbeded engineering data, etc. That would take a huge amount of research to get right, and if it weren’t, the system would probably just flag it as corrupt data and junk it.
Hacking in the other way (e.g. stealing the keys and taking Curiosity for a spin) is equally hard. The details required to build a valid command packet would require hacking into numerous secure databases, understanding all about the hardware (I’ve seen command dictionaries which just say a command “sets bits 4-7 on the FEE control interface.” So you’d need a bit more than the command dictionary.) Then you’d have to get it into the system and through the command approval process. Since there are usually several steps requiring human inspection and/or approval, that would be a good trick. There are some commands which bypass most of that process, but those commands are strictly limited to harmless things (e.g. take an image using the red rather than the green filter.)
I suppose on the issue of common mission software that the software costs are very low in the overall scheme of things; but proven code always trumps new code.
Thanks for the following explanations. Pleased but disappointed on some level. reading too much SF I think.
I cannot agree with the IG that administrative designations such as the ‘critical infrastructure protection program” provide the NEN with any material protection against intrusion or be worth the substantial administrative burden. The lack of any financial or military benefit from a hack make it an unlikely target and the nonstandard nature of the system and substantial technical capability of the operators make it a difficult target. The IG report fails to provide any evidence that any serious attempt at intrusion has ever occurred.