In 2018, NASA’s Jet Propulsion Lab (JPL) — a federally-funded research and development center that manages multiple deep space missions for NASA — was breached by hackers using a cheap, build-it-yourself Raspberry Pi computer. But that’s just the tip of the iceberg. An audit of JPL conducted by the Office of Inspector General has revealed considerable security weaknesses that put JPL — and by extension NASA and all the systems its connected to — at risk of high-impact breaches, data theft, and more. As the June 2019 report notes, NASA is a regular target of cyberattacks because the large size of the networks it maintains, its wide-ranging connections to other systems and networks, and the sensitive nature of the data data it stores. Specifically, its “substantial” links to other networks “presents cyber criminals with a larger more attractive target” and “offers cyberattackers multiple points of entry.” The report also notes that breaching NASA’s R&D “remains a priority for hostile foreign nations.” Given this, you might be shocked to learn just how vulnerable JPL has been to cyberattacks, but their security faults are actually all too common in organizations of all sizes. So what exactly happened with the JPL? Let’s break it down.
NASA’s JPL: A History of Cyber Breaches
Few organizations have the technical capability and as much computing experience as NASA, but even they have suffered a series of cyberattacks that penetrated their systems. In January 2009, a cyberattacker breached JPL and stole 22 gigabytes of data (including data protected under International Traffic in Arms Regulations and Export Administration Regulations), transferring the data to an IP address in China. Insufficient security at a number of network points gave the attacker full access to a multitude of sensitive data. After this attack, JPL deployed “host-based firewalls and intrusion prevention systems on workstations” to protect its network. This woefully inadequate security method left JPL blind to anything they didn’t have a software agent installed on, which leads us to… In 2011, JPL discovered another successful cyberattack in which intruders gained access to 18 servers supporting key JPL missions. The intruders were able to “(1) copy, modify, or delete sensitive files; (2) add, modify, or delete user accounts for mission-critical JPL systems: (3) upload hacking tools to steal user credentials and compromise other NASA systems; and (4) modify system logs to conceal their actions.” In this incident, the hackers went undetected for two weeks and were able to steal 87 gigabytes of data before detection. To prevent future hacks, JPL implemented tools to identify malicious activity, but based on what happens next, those tools weren’t exactly helpful.
In 2014, JPL discovered an infiltration in which malware was uploaded to a server supporting JPL missions and research. This was the result of a system admin installing a web-based program that allowed public file uploads and executions on the server. JPL implemented further security systems and network segmentation as a remedy this time. (Keep in mind, segmenting a network can create difficulties in managing them, especially if you are mass segmenting. Plus, segmenting has no real value if an intruder is able to route between the segments.)
In 2016, a web server misconfiguration allowed an unauthorized user to gain privileges that allowed this individual to “execute codes on a server used for architecture development,” which means this person could have embedded anything they wanted into the source code. JPL’s use of Secure Sockets Layer (which ensures encryption of data between a web server and browser) actually prevented them from being able to track what this individual did before being detected, which implies big problems if SSL is only assisting the hacker. In 2017, “a JPL server that runs source code used in ground operations for scientific spacecraft was comprised by foreign hackers who exploited a flaw in the software, hardware, or firmware that was previously unknown to JPL.” The hackers were able to remotely access the server, upload, manipulate and execute various files and commands. The OIG determined system patches had not been installed in time and the system owner had not reviewed logs to identify suspicious activity. JPL took some remediation steps after this breach, but they were far from enough.
NASA JPL’s Big Breach
Even after suffering breach after breach over the years, JPL still failed to put advanced cybersecurity in place that could keep up with the evolving threat landscape. In 2018, cyberattackers moved in again. That April, JPL discovered an external user account on its mission network had been compromised. Because of how JPL’s network was architected, the attackers were able to expand their access and move laterally through the network. The attack, classified as an advanced persistent threat (APT, almost always a nation-state backed hacking group), went undetected for nearly a year.
Upon investigation, it was discovered that the cause of the breach was someone connecting an unauthorized Raspberry Pi to the network. Once connected, the intruder was able to access two of JPL’s three primary networks, extracting “approximately 500 megabytes of data from 23 files, 2 of which contained International Traffic in Arms Regulations information related to the Mars Science Laboratory mission.”
Could ThreatWarrior have stopped these breaches?
Because of JPL’s ineffective security protocols and inability to manage assets connected to its network, it has been consistently unable to defend its network or respond to cyber breaches swiftly or successfully. So could ThreatWarrior have protected the organization from these cyber compromises? Short answer: yes. Many of the incidents above can be traced back to JPL’s poor asset management, inability to view devices connected to its networks, and inability to secure those networks. ThreatWarrior’s 3D Universe would illuminate JPL’s networks, showing them exactly what is connected and paths of communication between devices — highlighting where the need for segments may exist.
In its audit, the OIG found that, while JPL does track and manage physical assets, its database inventory is incomplete and inaccurate. ThreatWarrior’s automatic and continuous device discovery would inventory all devices observed on the network (even those added without clearance from JPL officials), and warn when new devices are added or appear after being offline for a period of time. Further, ThreatWarrior can autonomously isolate all newly-added devices from the network through ThreatQuarantine, which would have prevented the 2018 Raspberry Pi attack. ThreatQuarantine digitally suspends network access to suspect devices until security teams review and approve them. This can be done autonomously when suspicious activity is detected, or via defined protocols, such as “Immediately quarantine any new device.” For each of JPL’s breaches, ThreatWarrior’s next-generation capabilities would have protected the organization from compromise. 2009: In this breach, ThreatWarrior would have detected the large volume of data leaving the network, along with a device communicating outside of the network. It would have classified this behavior as abnormal and raised an alert for the security team. 2011: This breach was due to the ineffectiveness of log readers and software agents. Software agents can only protect what they’ve been installed on, and log readers can’t track an attack if the intruder modifies the logs. ThreatWarrior constantly tracks and records all network behavior and activity. It protects anything connected to the network, including embedded devices, IoT devices, security cameras, smart printers, etc. through agentless capabilities.
2014: Because ThreatWarrior self-learns the normal behavior of all devices and develops comprehensive device profiles, it can immediately alert security teams to any anomalous behaviors. When an intruder uploaded malware to the server, the malware would have created abnormal behavior and ThreatWarrior would have detected the server acting outside of its normal baseline. Additionally, ThreatWarrior’s ability to map a user’s network saves organizations from unnecessarily segmenting. (And to reiterate, segmenting as a solution is not nearly enough.)
2016: Unusual code execution on the server from an unauthorized user would have been identified as anomalous and raised for alert by ThreatWarrior. 2017: This hack is another highlight that log readers are not adequate cybersecurity. The system owner had to manually review the application log, which ThreatWarrior does autonomously. While log readers are an important part of a cybersecurity ecosystem, they alone are not enough to protect an organization from breaches. Additionally, when foreign actors executed code on the server without authentication, ThreatWarrior would have alerted the security team. 2018: Because JPL’s log monitors and software agents are not enough to effectively protect it, an external user was able to remain undetected in JPL’s system for almost a year. ThreatWarrior would have immediately alerted to and been able to quarantine the unauthorized Raspberry Pi connection. ThreatWarrior also would have shown any strange connectivity between systems and detected the security weaknesses. The length of this breach also shows JPL has serious issues with behavioral tracking, which ThreatWarrior excels at.
Recommendations to Improve NASA Cybersecurity
After its audit, the OIG had ten recommendations for NASA’s JPL: 1. Ensure proper inventory tracking with periodic reviews to guarantee compliance 2. Segregate shared IT environments and monitor partner activity on the network 3. Review and update partner Interconnection Security Agreements and ensure they’re made available to NASA 4. Improve ticketing systems and incident response procedures 5. Require JPL to complete validation of open waivers and provide NASA with documentation of them 6. Formalize cybersecurity responsibilities within JPL and monitor compliance 7. Implement the planned role-based training program by July 2019 8. Establish a formal, documented threat-hunting process with defined procedures and success metrics 9. Develop and implement a comprehensive strategy for institutional IT knowledge and incident management 10. Implement continuous monitoring tools that provide the NASA Security Operations Center with oversight of JPL network security practices NASA agreed to all of these recommendations except one — to put in place a formal threat hunting process. Instead, the organization continues to rely on ad hoc processes to search for intruders. The inspector general considers that one recommendation unresolved, but said the action plans for all others were “responsive” and those have been marked resolved.
Moving Forward: Is JPL’s Future Bleak or Bright?
Well, that depends entirely upon JPL and NASA. The organization is playing a dangerous game without formalizing a threat hunting program. The 2018 breach caused by a basic, easily available Raspberry Pi is a reminder that even an organization like NASA is at risk of cyber compromise if they aren’t implementing the correct tools to defend against it. ThreatWarrior would have been able to manage JPL’s assets, discover cyber intruders, and identify any strange behavior on the network, saving the organization from years of breaches. In alignment with the OIG’s recommendations, ThreatWarrior would enable JPL to gain a continuous asset inventory, monitor partner activity, improve ticketing and incident response, establish threat hunting and incident management processes, and implement continuous monitoring tools to provide NASA oversight of JPL’s networks. Given the sensitive nature of the data in its systems along with connectivity to other secure locations, JPL needs to be utilizing advanced cybersecurity that can proactively seek out and neutralize threats. When JPL is ready to protect its data with next-generation cyber defense that can comprehensively protect against APTs and other modern cyber threats, we would add one recommendation to the OIG’s list: Call ThreatWarrior. ___ To read the OIG’s audit report in its entirety, visit: https://oig.nasa.gov/docs/IG-19-022.pdf
