To Identity and Beyond: Identity and Access Lessons from the NASA Cybersecurity Report
On June 18, 2019, the Office of the Inspector General (OIG), Office of Audits released the Cybersecurity Management and Oversight at the Jet Propulsion Laboratory report. The report detailed six significant data breaches arising from computer networks operated by the Jet Propulsion Laboratory (JPL). The most recent one, in April 2018, arose from a compromised account belonging to an external user. As a result, NASA and JPL began reviewing network access agreements for their external partners. In short, stolen credentials led to malicious actors infiltrating JPL’s networks and systems for more than ten months. While much of the report discusses network security, the OIG report also contains an underlying identity and access management throughline that offers a cautionary vendor risk management tale for all organizations.
What Identity and Access Management (IAM) Issues Plagued JPL?
The OIG auditors reviewed a small sample of JPL’s infrastructure. According to the report, at the time of the audit, JPLs IT network included 26,714 computer systems and 3,511 servers. Of those, the auditors only reviewed 13 systems. These 13 system account for less than 1% (.0004) of the overall infrastructure. Thus, the OIG reports findings, when extrapolated across the overarching IT infrastructure, become even more alarming.
While the 43 page report details outdated patch updates and external vulnerability monitoring issues, embedded within these findings also lie several IAM issues.
Inadequate Segmentation of Network Environment
As part of the need for remote access, JPL established a network gateway. However, the OIG report notes that JPL did not appropriately limit user access only to the necessary systems and applications needed to complete job functions.
JPL’s inadequate limitation of access to “least privilege” necessary created the loophole that enabled a cyberattacker to obtain unauthorized access to sensitive data.
Ineffective IT Security Waiver Process
JPL’s system administrators could request waivers when they lacked the ability to resolve alerts within 6 months. Of the 153 open waivers, JPL had granted 54 to employees no longer working there.
Moreover, 2 of the 9 listed waivers involved Identity Governance and Administration (IGA). A waiver from December 2008 allows system administrators to disable user accounts rather than deleting them, to streamline provisioning should they return to the job. Another waiver in August 2009 allowed system administrators to “omit deleting user accounts.”
Another example the report provided highlights the OIG’s displeasure at JPL’s access governance processes. One project, granted a waiver for the 90 day password change control, relied on an application and team accounts to share password files, group files, host tables, and other files, attempting to create centralized account information by sharing user and group information across systems. Meanwhile, the application’s security weaknesses allows any user with an account access to any system using the application.
Lack of Access to Necessary Resources
When reviewing the log management and analysis, the OIG noted that 8 of 11 system administrators who should have been reviewing logs lacked access to Splunk ES. Meanwhile, the Security Operations Center (SOC) relied on the system administrators to be the first line of defense.
Lack of Appropriate Asset Inventory
The first rule of any information security program lies in appropriate identification of all system components. JPL’s web-based application, Information Technology Security Database (ITSDB), served as the authoritative source for certifying, accrediting, and authorizing physical assets and applications. Simultaneously, the Application Security Registry (ASR) within the ITSDB managed externally accessible applications that support critical functions. However, the weekly ITSDB updates required system administrators to add items manually, import the asset to the database, and later link it to a specific IT security plan.
In a footnote, the report explains that the manual process involves line managers identifying and creating IT systems in the ITSDB, appointing system representatives and administrators, reviewing and submitting IT system accreditation to authorizing individuals, and assigning IT assets, including virtual machines (VMs) and server-side applications.
The cumbersome manual inventory and approval processes in conjunction with a database whose updating function sometimes failed to work, left JPL with connected assets that lacked oversight.
Lack of Basic Contractual Protections
According to the OIG report, NASA and their vendor JPL engaged in shared business operations without an Interconnection Security Agreement (ISA) which would have defined the IT security requirements for connecting to IT systems and security controls for protecting data and systems. Additionally, NASA did ont establish an ISA with the external user with the compromised account.
In short, NASA, a governmental agency held to some of the highest regulatory requirements, lacked basic vendor risk management practices.
Where Did JPL and NASA Fail at Securing and Managing Identity?
The news cycle enjoys screaming “NASA data breach” at the top of its headline lungs. The external vulnerability monitoring issues and internal response issues provide another glaring example of failed cybersecurity controls. However, ignoring the IGA issues that exacerbated the monitoring, mitigation, and response weaknesses is both easy and harmful.
Maintaining Least Access Necessary
The lack of network segregation indicates a lack of appropriate access policies. By providing access to the entirety of the infrastructure, JPL left the networks open to all users.
JPL should have established identity-based access controls at both the application and network levels. The lack of appropriate access entitlements undermined the architectural segmentation.
Managing Identity Requires Detailed Entitlements
The waiver issue highlights another IGA problem. JPL needed an IAM solution that limited access and created timebound entitlements. The two waivers both lacked the necessary timebound deprovisioning that could have prevented data privacy and security issues.
JPL’s “disable not delete” waiver needed additional review. The lack of governance increased the data access risk. More concerning, however, is the lack of governance over the shared account. Access to the application left JPL’s network open to insider misuse and privilege abuse.
JPL should have ensured the review of all waivers pertaining to identity.
Providing the Appropriate Access to Necessary Resources
Of all the problems listed in the report, the system administrator lack of access to necessary reports causes the most cognitive dissonance. While other areas of the report indicated excess limitations, the system administrators were overly limited, leaving them unable to do their jobs.
JPL should have provided the appropriate access in a timely manner. Its inability to provide the right resources to the right people created a data privacy and security risk.
Appropriate Contractual Agreements to Manage Vendor Access
NASA failed to establish appropriate vendor risk management controls by not engaging in the required ISA. Not only did NASA fail to continuously monitor JPL’s cybersecurity control effectiveness, it also allowed unfettered access to its systems and networks.
NASA should have limited and monitored vendor access to its infrastructure, limiting the vendor to least privilege necessary.
Saviynt’s Assured IGA and Cloud PAM Compliance-as-a-Service
Saviynt’s platform enables organizations to secure their own infrastructures as well as restrict vendor access to their systems and networks.
Our role-mining capabilities incorporate context so that organizations can streamline provisioning of new users. Our peer- and usage-based analytics enable organizations to onboard users with access to necessary resources, preventing the access problems experienced by the JPL system administrators.
Meanwhile, our fine-grained entitlement provisioning enable organizations to limit access to meet “least privilege necessary” best practices. We can provision detailed access to networks, applications, and data within applications. With fine-grained entitlements, organizations not only set access rules for their employees but also for users outside the organization such as vendors and contractors. NASA’s lack of appropriate vendor contract could have been mitigated if the agency had protected access to its systems and networks with the appropriate controls.
Saviynt’s platform also provides peer- and usage-based analytics for continuous monitoring, alerting the organization to anomalous access and providing preventive controls for mitigating SOD violations. Saviynt’s platform also connects with UEBA and SIEM platforms to enable a holistic security program. Both NASA and JPL could have mitigated their risk by engaging in peer- and usage-based monitoring in conjunction with behavioral monitoring to prevent the excess access and unauthorized access from the external user’s compromised account.
Finally, Saviynt’s cloud-native Cloud PAM provides organizations a Privileged Access Management solution that meets the elasticity and velocity of the cloud. Our Cloud PAM continuously monitors for new workloads, instances, and containers so that organizations have continuous visibility into new risks. Legacy PAM products connect to the cloud rather than live in the cloud, which means that they create a time-lag for monitoring these new risks. JPL’s manual processes for VMs and APIs, and lack of monitoring over those identities, meant that they were unable to appropriately monitor these new cloud-based risks.
Saviynt’s starts with identity to help organizations protect their on-premises, hybrid, and cloud environments from the risks associated with access such as privilege misuse.