Defining linchpins: An industry perspective on remediating Sunburst

The Sunburst campaign underscored the inherent risk of technology to the public and private organizations who use it. It is important to examine what happened, look for opportunities to improve, and move forward. The Atlantic Council’s latest report “Broken Trust: Lessons from Sunburst” introduces the concept of “linchpins,” which it defines as “widely used software with significant permissions … on which every other security program or critical resource depends,” and which were a key factor in the Sunburst event. The report identifies challenges to identifying, securing, and triaging this linchpin software.  

This idea of linchpin systems is a potentially useful way to focus practitioner and policy analysis of critical shortfalls in cybersecurity. Like most private sector practitioners, we reviewed the linchpins concept and the report’s recommendations with an eye to practical implementation challenges. Philosophically, there is much consensus. Pragmatically, there are challenges which will need to be addressed in any recommended implementation plan. 

The report recommends securing linchpin technologies by identifying software with a significant “blast radius”—high impact to Federal objectives—and more closely securing and managing their use. Recommendations for public-private partnerships include sharing adversary trends, software deployment best practices, software bill of materials, improving open-source software management, and engaging industry CISOs to improve architecture.  These recommendations are to be led by at least five different agencies, leveraging activities already in progress—without one ring to rule them all. We believe more could be accomplished by fully embracing the welcome ideas of simplicity and flow through a simplified, centralized driving force to streamline the recommended actions. 

Applying federal risks to the private sector 

The report’s recommendations would require major cloud vendors to incorporate federal government risk models as priority guideposts in their feature roadmaps. We believe, however, that policy recommendations for industry cannot start from a government-first perspective. The public and private sectors share a combined technology ecosystem, and the public good of policies must enable and work for both. 

The ability of an organization to secure itself depends on risks in its ecosystem.

The ecosystems of federal military organizations, federal administrative agencies, the state and local public sector, and the private sector are variable and diverse. The Sunburst campaign was about espionage—using ubiquitous technologies supplied by the private sector to target federal agencies. This threat is high priority for federal agencies, but may appear less urgent to the private sector, or to state and local governments.  

Before requiring federal espionage risks to be prioritized in all ecosystems, we recommend validating whether such requirements serve a larger threat model.  

Furthermore, requiring the same actions of both large and small organizations may overwhelm those less well-resourced with non-actionable data or require security activities they are ill-equipped to perform. Policy makers must evaluate whether these additional recommendations are truly needed for greater general security, or only counter a niche threat. Intuitively, improving the security architecture of identity and access management (IAM) systems would protect against a variety of threats, but at what cost to vendors, the private sector, or consumers?

Without careful design, administrative rules that enforce federal government risk profiles may burden non-federal organizations. For example, requiring more detailed logs and incident response capabilities makes sense for larger organizations and federal agencies. Government-funded small vendor resource support, training, and workforce development would be necessary to support this objective for smaller organizations. 

Changing definitions may drive regulatory expansion 

The diversity of the ecosystem of technology products, services, and software underlines the need for consistent and consensus-driven definitions. These will be key to determining where the linchpin technology determination stops and starts. It is easy to name large providers like Microsoft, Google, AWS, etc. as having responsibility to secure software “linchpins” such as IAM technologies, but they are not the only vendors involved in the federal supply chain ecosystem. 

Is a linchpin defined as a system with a specific number of users? Is it defined by its level of privilege within a normally configured infrastructure? Or is it defined by some “blast radius” scenario, given a certain breach event? Answering “all of the above” may lead us down the path to yet another risk-based matrix that isn’t straightforward in interpretation or application. Without clear lines, the concept becomes opaque, and the security/compliance environment more complicated.  

Organizations are used to securing assets considered valuable because they are finished products, but we learned from Sunburst (and many similar supply chain attacks) that maintaining the integrity of the entire software development lifecycle is equally important; this adds a different risk definition to the term “linchpin.” At what point in the development process should a system be classified as a linchpin, with the accompanying controls and oversight? What about third-party add-ons and microservices, many of which are created by small vendors? If linchpin systems are the eggs, how can you separate and control the quality of the eggs once they are mixed and cooked with the rest of the cake? And how does this work when every organization is following a different recipe? 

We don’t expect to have answers to all these questions from the outset; what’s important is that the final definitions consider the fact that the adversary will always migrate to different parts of the attack surface as we make certain vectors more costly to exploit. A “linchpin” should not simply mean “a provider too big to fail,” nor should it mean “the most popular attack vector this year.” If the practical working definition of a linchpin is “widely used software with significant permissions … on which every other security program or critical resource depends” then before we indirectly manage it by imposing CMMC or other Federal risk management programs, we should explicitly decide how to embrace risk management so that it also works for the private sector ecosystem. 

Increased costs for software development and maintenance 

We applaud the Atlantic Council’s report for focusing its recommendations on software, particularly cloud-based software as a service. Delivery of software is complex and costly. Today vendors tend to handle the risk/cost tradeoff through dual tracking the development, maintenance, and support of software and infrastructure: FedRAMP or commercial. The provider can implement stricter (and costlier) controls for just the edition it intends to sell to the Federal government, rather than implementing such a high bar across the board that other customers may not want and can’t afford. If we are going to change this practice and require providers of linchpin software to be the rising tide that lifts all boats, the economic impact could well become a “blast radius” of its own.  

There has already been movement towards a federal structured and reviewed supply chain system, which has resulted in regulations like FedRAMP, CMMC, and others. The report encourages acceleration and, with the focus on pre-production controls, implicitly suggests the expansion of these programs. Consideration should be given to the risk/cost trade off of the oversight that is required as the operational and economic blast radius expands. These oversight programs are slow moving and expensive. There are multiple agencies involved, depending on how the data and systems are used, with duplicative reporting requirements. As a result, smaller vendors are filtered out of federal programs even while those vendors are being leveraged in the private sector and state/local governments.   

We support the idea of the continuous iteration of standards, rather than requiring net new or do-it-or-else compliance mandates. Federal regulations drive industry standards, not only for the companies who are directly part of the federal supply chain, but anyone in the vendor ecosystem. Applying production-level controls and testing to non-production software development environments will slow development and increase costs. Working to improve insecure systems is a worthy goal, but speed, agility and cost must be included in the risk/benefit tradeoff.  Without it, we risk limiting innovation and diversity of products, an outcome that is not in the best interest of the government or the broader community.  

Conclusion 

We commend the Atlantic Council for being a leader in these conversations and support the intent of the recommendations. We advise, however, that any proposed solutions be considered from the perspective of the entire community, not just the Federal government, as any recommendations will impact both the large vendors involved in the Federal supply chain, and any vendor in the non-Federal technology ecosystem. 

Simplifying and streamlining security for the Federal supply chain is an achievable goal, as long as strong relationships exist between policy makers and the security and technology community. 

Wendy Nather is the Head of Advisory CISOs for Duo Security and Cisco. Ms. Nather has over 30 years of experience in IT and security, where she has led technical security for financial services and served in state government.

Helen Patton is an advisory CISO at Duo Security and Cisco. Previously she was the CISO at The Ohio State University where she was awarded the ISE North American Academic/Public Sector Executive of the Year, and an Executive Director at JPMorganChase.