Welcome back to our Data Breach of the Month series, where we look at a notable cyber incident or data breach from the past month. Sometimes we’ll offer deeper analysis of the latest big breach, and other times we’ll focus on a lesser known incident that has outsized implications for the security industry.
In each case, you’ll learn the type of data breached, the vulnerabilities or gaps that were exploited, and what organizations can do to remediate effectively and address potential root causes.
So without further ado, our breach of the month for June, 2019 is… the recently announced hack at the NASA Jet Propulsion Laboratory.
On June 18, NASA released an audit report that revealed multiple data breaches that occurred over the past 10 years at the Jet Propulsion Laboratory (JPL) in Pasadena, California. One of the more significant breaches began in April 2018, when hackers accessed the JPL network and eventually stole information about missions to Mars. The hackers also accessed the IT network of NASA’s Deep Space Network (DSN), which communicates between satellite dishes and active spacecraft. The hackers went undetected for almost a year. Once the attack was detected, several NASA facilities disconnected from the JPL and DSN networks, fearing the hackers might pivot to their systems.
NASA classified the incident as an advanced persistent threat, leading to speculation that the hackers may be from APT10, a Chinese state-sponsored hacking group that has targeted NASA in the past.
How Did it Happen?
The hackers used a compromised Raspberry Pi to connect to the JPL IT network and bypass security controls. They then used a share network gateway to move deeper into the network, eventually reaching the Mars mission information.
The JPL’s information tech security database (ITSDB), which is used to monitor physical assets and applications on its network, was found in the audit to be entirely inaccurate. This allowed for blind spots regarding what devices were connected to the network, such as the compromised Raspberry Pi. The JPL also failed to practice proper network security, without proper segmentation and access controls that would have made it harder for hackers to move within the system.
The JPL staff also failed to respond effectively to issues. The audit found that tickets for reported vulnerabilities were not promptly resolved, sometimes remaining open for six months at a time. This may be because NASA’s SOC did not have incident responders available at all time and did not always follow federal incident response guidelines.
How to Minimize the Risk of this Type of Breach
The audit report made 10 recommendations for improvements. These include properly managing the ITSDB, segregating the network, improving the security problem log ticket process, and implementing a role-based training program. NASA agreed to nine of the ten recommendations, rejecting only the recommendation to establish a formal threat-hunting team.
While all the recommendations will help the JPL improve on what has apparently been a decade of poor security practices, not implementing a threat-hunting team seems like a missed opportunity because of how slow the JPL has been to detect intrusions. Enabling threat hunting is just one of the use-cases for D3’s ATTACKBOT, which has embedded the entire MITRE ATT&CK framework for intelligent intent-based correlation of security events. ATTACKBOT uses a predictive kill chain to find and reveal actions that on their own might seem innocuous—such as someone accessing a database with NASA mission data—but when viewed in context start to form the pattern of a cyber attack.
You can read more about the numerous use-cases for ATTACKBOT in our white paper here.
Thanks for joining us. We’ll see you back here next month for a new Data Breach of the Month.