A new age of space exploration is on the horizon. From formal space research conducted by the International Space Station, satellites, and NASA to recreational jaunts into zero gravity by Captain Kirk, technology is enabling humans to get closer to the stars than ever before. But this new space age brings with it new security concerns and challenges that need to be met with modern solutions.
In this blog, we will explain how and why microsegmentation, specifically application-centric zero trust microsegmentation (it’s a lot of buzzwords, I know, but I promise you the read is worth it), could have prevented the April 2018 breach of 500 MB of data related to Mars mission and protected against all of the 2009-2017 Jet Propulsion Laboratory (JPL) network compromises.
Security basics newcomers
Of the network security control recommendations listed in the Cybersecurity Management and Oversight at the Jet Propulsion Laboratory report, only two items are relative “newcomers” to the security fundamentals scene: threat hunting and microsegmentation. While it can be argued that threat hunting is an advanced security technique reserved for organizations with sufficient resources—namely, the likes of NASA—microsegmentation is quickly becoming a security fundamental. Several analyst firms say microsegmentation is a core capability. The Office of Inspector General (OIG) agrees, according to multiple mentions in its 49-page report. In addition to listing microsegmentation as the #2 security control issue in JPL's critical systems and the #2 recommendation for preventing further compromise and data breach, the OIG had the following things to say about the JPL breach:
“...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.”
“JPL established a network gateway to allow external users and its partners, including foreign space agencies, contractors, and educational institutions, remote access to a shared environment for specific missions and data. However, JPL did not properly segregate individual partner environments to limit users only to those systems and applications for which they had approved access. By properly segmenting a network, an organization creates boundaries an attacker cannot cross by eliminating connections to other systems. As a result, the shared environment lacked appropriate security controls to prevent partners from accessing a variety of exploration and human space flight mission data.”
Microsegmentation as a compensating control
Every item on the OIG’s list of cybersecurity failures-turned-recommendations is important. That said, only properly-implemented microsegmentation—in absence of every other security control named—could have prevented threat actors from moving laterally between systems in JPL’s networks, accessing a key database, and removing 500 MB of sensitive data related to space exploration...or accomplishing any of the other nefarious things attackers they did in prior years’ escapades.
While the report doesn’t say explicitly, it’s likely that JPL was using firewall-based zoning, where it was implemented at all (given that firewalls are mentioned specifically in the report). Though firewalls are excellent at preventing north-south traffic on the network, address-based microsegmentation is complex, time-consuming, and too resource-intensive for even the most advanced security organization to manage. Because addresses can only tell the organization where a system request is coming from and going to, they’re not very good indicators of advanced compromise, e.g., how a nation-state would stealthily and over long periods of time access proprietary space data.
IP addresses can be spoofed or hijacked by attackers (attackers don’t even have to be particularly sophisticated to accomplish either action), making it relatively easy for them to hide their actions in permitted traffic and bypass address-based security gateways. If the network in question is in a cloud environment, addresses are even more ephemeral and unreliable (in the case of JPL, even if its systems are predominantly on-premises, it is likely their vast partner network includes numerous cloud-based environments). As such, the network itself isn’t the strongest control plane for NASA’s databases and servers.
Zero trust + software identity = strong microsegmentation
By using zero trust microsegmentation tied to the cryptographic identity of the applications and services NASA needs to protect, the agency could kill many birds with one stone, so to speak. Application-centric microsegmentation results in a complete inventory of all communicating entities on the network. Why? Because, before it’s allowed to communicate, every entity must be identified by its unique identity. This method results in full network topology identification and mapping. In other words, if JLP’s IT staff failed to log a new database with, say, information about an upcoming launch, application identity-centric microsegmentation would see a new communication request. Further, once a new deployment has been approved for communication, dependency mapping is logged and can therefore be managed.
In the case of a faulty ticketing and remediation process, application-centric microsegmentation could also be a compensating control. Let’s say JPL’s operations team failed or was unable to patch software, hardware, or firmware in a timely manner. Microsegmentation could be used to isolate vulnerable systems until a patch could be applied. Zero trust microsegmentation could enforce least privilege access, ensuring only the systems that must have access the affected system have access, thereby containing the extent of any potential damage. Ring fencing specific databases and servers in this way would have prevented several of JPL’s breaches from the last 10 years.
When it comes to failure to document security requirements for partners, zero trust microsegmentation would be a compensating control here, too. Staff members who are unsure of their role or who haven’t taken the time to update and disseminate security requirements to partners whose networks touch JPL’s networks are removed from the equation. Why? Because all unidentified communication requests are blocked in a zero trust network, and any system that doesn’t meet certain patch or version levels, that contain known-bad software, or that violates terms of access is blocked from communication. In this way (much like asset inventory), JPL would know immediately if a partner or individual system was not in line with requirements.
Conclusion
Lateral network movement was a key factor in the April 2018 JPL breach as well as its previous security incidents. It is a key factor in many other high-profile breaches we’ve seen in the last decade, too. So why aren’t more organizations doing it, especially if microsegmentation can compensate for other security fundamentals failings? Because the perception is that it’s too hard, that it slows down the network, that it’s an operational nightmare to maintain, and that it doesn’t provide enough security ROI to justify the ongoing effort.
These things are only true if your microsegmentation project is based on legacy controls and is tied to network constructs. Modern microsegmentation is decoupled from the network so that organizations can protect what’s most important: data-rich applications and services. Application identity-based microsegmentation paired with zero trust removes complexity, is stronger than any address-based segmentation, and scales as your networks do. A modern security solution that’s equipped with microsegmentation capabilities is necessary to secure the new space age and ensure organizations have a successful launch into the digital age.
