On 21 June, 2019 major news channels disclosed a major hack on NASA. Hackers were able to gain unauthorized access using Raspberry Pi and stole ‘Mars Mission Data’ and breached ‘NASA’s satellite dish network’. This happened around April 2018 and went unnoticed for for almost a year.

1. IT Asset inventory was incomplete and inaccurate: Multiple IT security control weaknesses reduce JPL’s ability to prevent, detect, and mitigate attacks targeting its systems and networks, thereby exposing NASA systems and data to exploitation by cyber criminals. JPL uses its Information Technology Security Database (ITSDB) to track and manage physical assets and applications on its network; however, we found the database inventory incomplete and inaccurate, placing at risk JPL’s ability to effectively monitor, report, and respond to security incidents. Moreover, reduced visibility into devices connected to its networks hinders JPL’s ability to properly secure those networks. Further, we found that JPL’s network gateway that controls partner access to a shared IT environment for specific missions and data had not been properly segmented to limit users only to those systems and applications for which they had approved access. This shortcoming enabled an attacker to gain unauthorized access to JPL’s mission network through a compromised external user system. Additionally, NASA failed to establish Interconnection Security Agreements (ISA) to document the requirements partners must meet to connect to NASA’s IT systems and describe the security controls that will be used to protect the systems and data.
2. Threat Hunting Program & Security Training Not Implemented: The security problem log tickets, created in the ITSDB when a potential or actual IT system security vulnerability is identified, were not resolved for extended periods of time—sometimes longer than 180 days. Further, JPL system administrators misunderstood their responsibilities regarding management and review of logs for identifying malicious activity occurring on a particular system or network. We also found that while cybersecurity monitoring tools employed by JPL defend against routine intrusions and misuse of computer assets, JPL had not implemented a threat hunting program recommended by IT security experts to aggressively pursue abnormal activity on its systems for signs of compromise, and instead rely on an ad hoc process to search for intruders. In addition, JPL had not provided role-based security training or funded IT security certifications for its system administrators
3. Inadequate Incident Management & Response Practices: Further, we found that multiple JPL incident management and response practices deviate from NASA and recommended industry practices. For example, unlike NASA’s Security Operations Center (SOC), JPL’s SOC does not maintain round-the-clock availability of IT security incident responders and JPL’s incident response plan does not include all federally-recommended elements. In addition, team coordination issues delayed completion of incident containment and eradication steps for the April 2018 incident. Moreover, while documenting and sharing cyber threat information across JPL to help prevent future incidents is a critical component of an effective incident response program, we found JPL’s current initiatives fall short.
4. Missing Controls For Compliance Implementation: Finally, while the contract between NASA and Caltech requires JPL to report certain types of IT security incidents to the Agency through the NASA SOC incident management system, no controls were in place to ensure JPL compliance with this requirement nor did NASA officials have access to JPL’s incident management system. Collectively, these weaknesses leave NASA data and systems at risk