![](https://www.techmonitor.ai/wp-content/uploads/sites/29/2019/06/raspberry-pi.jpeg)
Unknown hackers used a Raspberry Pi attached without authorisation to a NASA network at its Jet Propulsion Laboratory (JPL) to infiltrate — then move laterally across —NASA networks; exfiltrating 500MB of data, unnoticed, from 23 NASA files over a 10 month period.
The news is among the bleaker revelations for NASA’s security team in an damning security audit by the NASA Office of Inspector General (OIG) published this week, which reveals that the unknown attacker went on to successfully access two of the three primary JPL networks.
The audit does not specify who placed the Raspberri Pi — a credit card-sized computer — on the network (it could have been a staffer without malicious intent) but notes that inadequate identification of system components and poor network segmentation mean it would not have been hard: “Assets can be added to the network without being properly identified and vetted by security officials.”
The JPL —which employs over 6,000, and in which in 2018 had a $2.5 billion budget — manages NASA’s Deep Space Network, a worldwide system of antennas that communicates with interplanetary spacecraft, including the International Space Station.
The breach left NASA officials questioning the integrity of data related to space flight systems and disconnecting several space flight-related systems from the JPL network, the audit reveals.
The report, which reveals a litany of security failings, says the investigation into the network breach, first discovered in April 2018, is ongoing: “In response to the attack, JPL installed additional monitoring agents on its firewalls and continues to work with NASA to review network access agreements.”
Red Flags Over Poor NASA Network Segmentation
In further revelations, the audit reveals that a network gateway set up by JPL to allow external partners (e.g. foreign space agencies, contractors, and educational institutions) remote access to a shared environment for specific missions, did not segregate individual partner environments. This should have limited users only to those systems and applications for which they had approved access.
“As a result, the shared environment lacked appropriate security controls to prevent partners from accessing a variety of exploration and human space flight mission data.”
Fears over this poor network segmentation led IT security officials from the Johnson Space Center (Johnson), which handles the International Space Station, to disconnect from the gateway due to security concerns.
” Johnson officials were concerned the cyberattackers could move laterally from the gateway into their mission systems, potentially gaining access and initiating malicious signals to human space flight missions that use those systems. At the same time, Johnson IT security officials discontinued use of DSN data because they were concerned it could be corrupted and unreliable.”
Marco Rottigni, Chief Technical Security Officer EMEA at Qualys, told Computer Business Review: “The first problem [in instances like this] is many companies don’t have a single source of truth on the assets they have. At all. You can’t look at how your security controls are applied on things you don’t know about.”
“The second problem is that there are more platforms in place – endpoints, cloud, containers – and each of them have different best practices for security. So it’s not just a question of what you know about, you also have to set out and follow those practices across all your assets as standard, rather than allowing variations in approach. Companies still have to get the basics right: you need full visibility and accurate information at scale.”
The news is just the latest in a string of security incidents at the space agency. As Computer Business Review reported in December, the agency acknowledged that NASA’s HR servers had been hacked, exposing the details of staff with NASA since 2006. That breach was discovered in October 2018.
See also: NASA Servers Breached: “A Top Agency Priority”
Top image credit Christian Haschek – and from this incident, not the NASA one…