The question What information was stolen from JPL during the Raspberry Pi hack? refers to an event in recent news (e.g. Engadget's A rogue Raspberry Pi helped hackers access NASA JPL systems) and references NASA's Office of Inspector General June 2019 report Cybersecurity Management and Oversight a the Jet Propulsion Laboratory which states on page 17 in the section titled Incomplete and Inaccurate System Component Inventory:

Moreover, system administrators did not consistently update the inventory system when they added devices to the network. Specifically, we found that 8 of 11 system administrators responsible for managing the 13 systems in our sample maintain a separate inventory spreadsheet of their systems from which they periodically update the information manually in the ITSDB. One system administrator told us he does not regularly enter new devices into the ITSDB as required because the database’s updating function sometimes does not work and he later forgets to enter the asset information. Consequently, assets can be added to the network without being properly identified and vetted by security officials. The April 2018 cyberattack exploited this particular weakness when the hacker accessed the JPL network by targeting a Raspberry Pi computer that was not authorized to be attached to the JPL network. 32 The device should not have been permitted on the JPL network without the JPL OCIO’s review and approval.

Question: I'm asking for a better understanding of the explanation given related to the Raspberry Pi incident. Is the failure to keep an updated list of authorized devices a central cause or primary contributing factor to the breach, or is the list a peripheral issue and the network should have been secure against connection of any Raspberry Pi, authorized or not.

This answer starts to outline the seriousness of the breach.

  • You pick only a single problem from the report which includes many other problems. And it is not clear for me why you pick specifically this problem. "if they'd only had better record-keeping, this wouldn't have happened" - the report does in no way claim this. Again, this is just one of many shortcomings mentioned in the report and it is not sufficient to fix only one of these to be secure. "Shouldn't such a valuable US government network be secure against all connections equally, authorized or not?" - wouldn't this be the goal for all networks? Only, it takes lots of time and resources. Commented Jun 24, 2019 at 6:45
  • @SteffenUllrich Thanks for your comments. The reason that I picked this specific problem is explained in the first sentence: "The question... refers to an event in recent news". You are right that the report highlights a number of issues, but it's the Raspberry Pi's unauthorized connection that I've read so much about and so this is the aspect of the report that I'm asking about.
    – uhoh
    Commented Jun 24, 2019 at 6:49
  • Sure, but again the report does not claim that fixing this single issue would also fix the security. And it was not enough for the breach that there was an unauthorized RasPi - this was only the entry point and the attacker could move from there undetected because of all the other problems. Commented Jun 24, 2019 at 6:57
  • 1
    I'm not completely sure what you are asking @uhoh. Are you asking whether standards say this should be prevented, or whether it could have been detected? If you are asking for the basics of a security program then it's too broad.
    – GdD
    Commented Jun 24, 2019 at 7:00
  • 1
    That's answerable @uhoh, you could just cut and paste that comment into the question I think to clear it up.
    – GdD
    Commented Jun 24, 2019 at 7:42

1 Answer 1


There's no one central cause, the breach was a product of multiple failures. Like space launch failures or airplane crashes it was a cascade of failures, preventing one of them would have at least lessened the severity of the breach:

  1. Poor training and security awareness: putting a raspberry PI on the network was a big no-no, the user who did it shouldn't have done it and colleagues should have spoken up
  2. Problems weren't fixed: the security operations group were massively behind in investigating incidents. Because it took so long to resolve tickets people may have stopped reporting issues, which may have contributed to 1
  3. No VMS (Vulnerability Management System): A VMS is technology and process to scan for and remediate vulnerabilities on a network. The technology side is agent or engine based and set up to sweep an entire network in a discovery scan and then do a deeper scan on detected devices in order to determine a) what they are and b) what vulnerabilities they may have. The process side is for the the information to be used by automated systems or interpreted by people to find the threats. A halfway decent VMS would have found that PI and action would have been taken to get it off the network
  4. Poor network protection: there's several issues, the firewall rules to limit access from one network to another were wide open, and access to the network wasn't limited to only recognized devices. If the firewall rules had been stronger or the JPL had been tighter in permitting only recognized devices on sensitive networks then the breach would have been mitigated or prevented

If I had to sum it up in a single line, the breach was due to the lack of a robust security program with a failure to maintain defense in depth.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .