In the weeks since news of the SolarWinds incident became public, commentators have offered no shortage of prescriptions for responding to the incident. But as information continues to emerge about the scope and scale of the incident and policymakers struggle with thorny questions regarding appropriate responses, urgent attention also is needed to actions that could prevent such large-scale catastrophes in the future.
The suspected Russian hack into SolarWinds software – and, as is becoming apparent, into a limited number of other software products around the same time and earlier as well — is a reminder of the systemic security risks posed by outsourcing IT to cloud-based providers of “Infrastructure as a Service” (IaaS) and “Software as a Service” (SaaS). In the case of SolarWinds users, for example, after inserting malware into the network management software and gaining access to the on-premise infrastructure of the company’s clients, the perpetrators turned their attention to the cloud, deceiving user authentication protocols into allowing access to cloud resources.
To address these vulnerabilities, federal action is needed to establish a cloud security certification that can help deploy security across the ecosystem of information and communications technology, starting with the cloud.
Both IaaS and SaaS providers are attractive options for customers because they offer usability and scalability. Rather than assuming responsibility for building and maintaining on-premise infrastructure, consumers place their trust in companies like Microsoft and Amazon Web Services (AWS) to secure their data. In theory, if IaaS and SaaS providers take security seriously, customers benefit from the deployment of security at scale. In practice, however, security costs money, and IaaS and SaaS providers are not necessarily more security-conscious than their customers. And relying on IaaS and SaaS providers does not relieve customers of all compliance obligations.
In the SolarWinds case, attackers abused the trust placed in on-premise systems to forge credentials that allowed them to access cloud systems and escalate their attacks across compromised networks. The perpetrators did not need to compromise cloud systems themselves. Once equipped with a foothold in victim networks, they had everything they needed to spread out across the network. The incident thus demonstrates on a granular, victim-by-victim scale the potentially significant, systemic risks associated with the cloud: Gaining access to a crucial node can enable widespread damage across an entire system.
Though proper configuration of authentication and authorization systems can serve as crucial mitigation procedures in the SolarWinds case, they require customers to understand the level of security provided by IaaS and SaaS products and the shared responsibility model that underpins security protocols. Customers often lack information about the specific contours of shared responsibility for the proper configuration of IaaS and SaaS products. Existing product certifications and compliance attestations — for example, the Cloud Security Alliance’s STAR Program or ISO/IEC’s 27017:2015 guidelines — confirm product compliance with security requirements. However, the dozens of available certifications and standards meant to assure that products meet customer or regulatory requirements for the protection of data, authentication of user identities, or infrastructure protection can be overwhelming. Information is only useful to customers if they have the tools to make sense of it.
In its March 2020 report, the Cyberspace Solarium Commission called on the Department of Homeland Security (DHS) to work with the National Institute of Standards and Technology (NIST) and private industry to develop a cloud security certification. While it is true that myriad certifications of IaaS and SaaS products have been developed by industry — AWS alone boasts participating in more than 50 audit programs — standards that can be easily compared across products remain undeveloped. A federal cloud security certification can incentivize providers to deliver better security and buyers to buy better security by consolidating information and enabling product comparisons.
Such a certification is not without precedent. In 1992, the Environmental Protection Agency (EPA) launched the ENERGY STAR program to provide simple, credible information about the energy efficiency of consumer products through a public-private partnership. The program has been remarkably successful — more than 6 billion ENERGY STAR-certified products have been sold since the program’s inception in 1992.
A federal cloud security certification would operate largely in the same way: Providing simple, credible information to consumers about the security standards offered by cloud products and services. The executive branch should direct DHS and NIST to engage in a public-private process to develop a secure cloud standard and metrics for comparing security across products and services. Given the rapid pace of innovation in cloud computing and storage, a federal cloud certification should last two years, and DHS should be empowered to conduct subsequent audits of entities that apply for certification.
Rather than proposing entirely new standards and metrics, the federal certification would help consolidate existing efforts, relieving customers of the obligation to wade through dozens of certifications in order to compare products. The certification would also potentially relieve IaaS and SaaS providers of the obligation to pursue multiple security and compliance certifications by providing a single authoritative certification. The fact that the federal certification would consolidate existing industry certifications — and possibly replace the convoluted FedRAMP program — rather than propose entirely new frameworks, can help secure buy-in from industry participants that may balk at the idea of yet another security or compliance certification. Moreover, the certification would be voluntary, leaving resistant IaaS or SaaS providers free to decline participation in the program.
Critically, such a certification would also communicate to customers their own remaining responsibilities for properly configuring devices and networks. Knowing the security features that are not overseen by an IaaS or SaaS provider is as important as knowing those that are.
Additional Security for Certain Operating Environments
The Solarium Commission also recommended that, in addition to a general cloud certification, DHS develop industry- and sector-specific standards that guarantee additional security features for operating environments, like the public sector, that have unique security considerations. Because federal departments and agencies also rely on commercial IaaS and SaaS, a cloud security certification would benefit efforts to ensure that IT products meet appropriate security levels for use in federal systems and can adequately protect classified information.
Established in 2011, the Federal Risk Authorization and Management Program (FedRAMP) currently authorizes cloud service providers for use by federal departments and agencies, and it maintains frameworks for security assessments, authorizations, and monitoring. The FedRAMP process, though critical, is cumbersome, and the program has limited resources and funding. As a result, existing demand for a cloud service provider’s products and services or established relationships with federal departments and agencies, are important indicators of whether Cloud Service Providers (CSPs) will be selected for FedRAMP authorization.
If successfully executed, a federal cloud security certification program could relieve FedRAMP of some of the responsibility to certify CSPs for federal use. Doing so would potentially enable a greater number of cloud service providers to enter the market for federal IT contracts, and this, too, can help secure industry support for a federal certification. Entities eligible for certification would include any cloud service provider or operator of cloud services, rather than those with existing federal relationships or significant market share.
NIST has previously conducted work related to cloud computing through the NIST Cloud Computing Program. In 2018, the program published a framework for Cloud Service Metrics (CSMs) that would enable CSPs to present the properties and capabilities of their products to customers and help customers make informed purchasing decisions. NIST has also addressed cloud security in its roadmap for federal cloud computing standards, surveying the landscape of existing security standards that have been proposed by standards-developing organizations. NIST should build on these previous efforts by working with DHS to deliver a federal cloud security certification.
Similar efforts have been undertaken in Europe, where the European Union Agency for Cybersecurity (ENISA) recently published a candidate scheme for cloud security certification as part of the European cybersecurity certification framework. A public consultation period on the candidate scheme concluded Feb. 7. ENISA has previously worked with the European Commission and a group of industry experts to compile and maintain a list of existing voluntary certification schemes and develop a “meta-framework” and online tool that helps customers map cloud security objectives to specific certifications. The U.S. government can look to European counterparts as an example, and the process of developing the federal cloud security certification should involve consultation with ENISA to ensure, to the extent appropriate and possible, that the two certification schemes complement one another.
Not a Panacea
In the waning days of his administration, President Donald Trump signed an executive order (EO) mandating that cloud service providers adopt know-your-customer (KYC) practices to prevent foreign adversaries from using American IaaS providers to carry out their attacks. then-National Security Advisor Robert O’Brien pointed to the SolarWinds incident in a statement on the EO, describing how “Malign actor abuse of United States IaaS products has played a role in every cyber incident during the last four years, including the actions resulting in the penetrations of United States firms FireEye and Solar Winds.”
While this is an important step forward, the reality of the SolarWinds situation is that the perpetrators weren’t cloud customers and KYC practices wouldn’t have stymied their efforts. The burden of responsibility for securely configuring the authentication systems abused by the SolarWinds hackers still rests on IaaS and SaaS customers.
Despite its potential utility to consumers and the federal government, a cloud security certification is not a panacea. Even certified systems operated by engaged, knowledgeable users can be breached, and capabilities for threat detection and incident remediation and response must be bolstered alongside defenses. The perpetrators of the SolarWinds incident were able to evade detection for months. The only government agency with the capability and capacity to look for this sort of malicious activity, the National Security Agency, has significant legal prohibitions on its engagement in domestic surveillance. As the scope and scale of the SolarWinds incident continues to come to light, further action will be needed to ensure that cyber threats can be identified and mitigated in a timely fashion.
In the meantime, as victims of the SolarWinds incident attempt to determine the extent of the damage and identify appropriate responses, identifying tools to help prevent future incidents must be a priority for policymakers, and the executive branch should direct DHS and NIST to begin the process of developing a federal cloud security certification. The SolarWinds attack has demonstrated the importance of clearly and effectively communicating to customers the level of security they can expect from their cloud providers and the responsibilities that remain with users. Implementing a cloud security certification is an important first step in empowering customers in this endeavor.
(Editor’s Note: The second paragraph of this article was updated after publication to add that the hacking incident appears to have affected a broader and earlier set of users than just SolarWinds customers.)