(NASA Hacked) 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. It is advisable to do an attack surface analysis for an organization to have a know-how of all the access and assets.
Why It Happened ?
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
Audit Recommendation From Office of Inspector General
To improve JPL network security controls, NASA Office Of Inspector General recommended the Director of the NASA Management Office instruct the JPL Chief Information Officer (CIO) to:
(1) Require system administrators to review and update the (Asset Inventory) ITSDB (Information Technology Security Database) and ensure system components are properly registered and the JPL Cybersecurity/Identity Technologies and Operations Group (CITO) periodically review compliance with this requirement.
(2) Segregate shared environments connected to the network gateway and monitor partners accessing the JPL network
(3) Review and update ISAs for all partners connected to the gateway
(4) Require the JPL CITO to identify and remediate weaknesses in the security problem log ticket process and provide periodic ageing reports to the JPL CIO
(5) Require the JPL CITO to validate, update, and perform annual reviews of all open waivers
(6) Clarify the division of responsibility between the JPL Office of the Chief Information Officer and system administrators for conducting routine log reviews and monitor compliance on a more frequent basis
(7) Implement the planned role-based training program by July 2019
(8) Establish a formal, documented threat-hunting process
(9) Develop and implement a comprehensive strategy for institutional IT knowledge and incident management that includes dissemination of lessons learned
It also recommended the NASA CIO include requirements in the pending IT Transition Plan that provide the NASA SOC with sufficient control and visibility into JPL network security practices
A digital footprint scan could have proven very helpful in this scenario as NASA would have been aware of its external user account and could have taken measures to protect it.