If your company relies upon software from any third party, (and frankly today is there any organization that doesn’t) there is a third-party risk out there you are probably ignoring. It’s unlikely you wrote your own internet browser, or email system, word processor, or spreadsheet programs, or network management systems. It’s equally unlikely you are operating without some software you licensed, and perhaps some maintenance tools to run it all. And when you did so, you probably purchased some period of support for updates and upgrades. So, here’s a question: “How do you secure and validate the integrity of promoted service packs, updates, and upgrades?” What controls do you have in place to assure the software you’re downloading is coming from a reliable, vetted source, contains only the code intended, and is safe to operate? For all those thousands of firms relying upon SolarWinds for distribution those maintenance releases from their management products, the risk has become a reality.
Where We Are
Trusted sources of critical resources have long been a target of malicious actors. If you want to breech the walls of a secure place, infect some resource provided by a trusted partner, and pass through undetected. It’s an ancient strategy, still in use because it works. SolarWinds, an IT service management software company, delivered software to many firms and platforms, networks, and devices within them. When its trusted updates were compromised, they passed through client perimeter defenses, and infected machines throughout their technology infrastructure. The extent is still being calculated. Software updates from trusted partners should be reliable. We count on that. We expect it to be so. All too often the controls around securing these distributions and downloads rely mostly upon the overall security provisions of trusted company-to-company relationships. We trust reputations, brands, and noted past results. We could, and need to do more.
Policies Going Forward
Policies and procedures may seem like a strange place to start. But they are the “what and why” behind the “how” control details often measured and examined to assess risk. Inspection schemes alone do not address every aspect of a risk situation, but they do establish clear bedrock and the means to measure departure from preferred or expected states. Your risk and security policies, and supporting procedures define the key provisions of your program. They inform the intent, reasoning, and means to addressing specific aspects of risk. They tie your program to frameworks and standards, and provide guidance to the definition, data sources and calculations of leading and training metrics. Policies and their supporting procedures communicate the importance and underlying contributions to your business made by risk management and security. Where there are gaps, there are the implications of unimportance. People notice gaps, and where they are implicit will sometimes presume not only their existence, but dismiss as unimportant, what appears to be missing.
Policy may be viewed as something static, set once firmly, rarely or never to be altered. That thinking has long been overturned by the dynamic, fluid business environment of today. Change is now the constant, with only its rate being variable. While some overarching mission and philosophy statements may continue to be comparatively firm, policy and procedure need to address change, and be structured to allow informed interpretation and action to address current and foreseen situations. This means your policy and procedure practices must support monitoring for continued relevance, a means for managing change, communications and publications methods to inform constituents and stakeholders, and versioning practices to assure your staff that they are reviewing and implementing the most current versions and practices. This also bears relevance to compliance, audit, and operational practices which all have dependencies upon policy in force.
Coming back to software supply chains, the practices surrounding their security and verification of authenticity should be addressed by policy, to affirm the importance and reasoning for doing so, and procedure, so that, by intent, it describes what needs to be done to assure both. Information technology has become a foundational discipline for every business today. It will continue to become entwined into how we do what we do in the future. Business and society at large are not likely to regress from where we are. Pandemic response has increased our dependence upon technology — something likely to endure beyond its end. Security and operating policies, as well as those for IT must articulate the need to secure the software supply chain, regardless of source. Synopsys has noted that 99% of commercial software programs include at least one open-source component.[1] Do you have policies addressing the use and management of open source software?
Actions To Take Now
If you are operating a risk-based approach to security you have the bones of best practices in place. Specifically, your program proscribes:
- Careful, regular backup of development and production environments, including the periodic testing of these to assure they are valid and reliable
- Identification, assessment and prioritization of critical assets to be maintained
- Staff education on the importance and processes of software supply chain security
- TPRM — understanding how your software providers are securing software and its delivery
- Risk-based recovery practices — having these in place, documented, and vetted should they become needed
- Security policies reviews — to ensure those addressing the above practices incorporate guidance on practices for managing your software supply acquisition, update, and upgrades.
In addition, there are some other actions to consider, based upon your own risk assessments:
- Hardening software build environments
- Educating developers on software build and subcomponent inclusion best practices
- Implementing vulnerability detection tools and integrate into the development process
- Determining whether any subcomponents have known vulnerabilities
There are a number of secure software supply chain tools and processes being considered and under development for the future. Many are either still too immature to be effective or prohibitively costly and narrow in applicability. The best practices for TPRM (Third Party Risk Management), discussed at length in preceding blog posts, would serve companies well to extend and apply to their software supply chains. This effort should not be restricted to major enterprise (ERP) or operating systems alone. The risk extends to sources for routine updates to desktop productivity suites and networking software. Companies need to know, and staff need to understand and follow best practices to assure updates for all software comes from reliable sources that attest to vetting of their product.
Leverage Your GRC
So, how may your GRC help? If you look at the list of actions, they all are represented in some form by the controls and practices inherent in cyber security frameworks and comprehensive risk assessments. If these controls have not received attention in your risk management practices in the past, reassessment of their priority and potential severity may be appropriate now. Assessment for software supply chain is just one specific TPRM use case. If you already have these in process at your firm, you are positioned to act regarding this threat. If not, this is one more good reason to implement a comprehensive TPRM process, either as a supplement to your GRC tools, or as a first step on the path to their integration into your risk management program.
Look at the results of recent and prior risk assessments. How strong are your controls and practices related to backup, recovery, critical asset identification and protection? Does your staff education specifically address concerns and best practices around software supply chain management? Are your software development processes and work environments hardened to be secure? Can you identify which controls are in force and effective across all aspects of your enterprise? Are the weakest areas prioritized for remedial attention this year? Where projects are underway, are they progressing well? On-time? On-budget? The value of a GRC tool and its flexible reporting features is in its ability to support reliable answers to these questions when you need them most.
Looking Ahead
There are no easy answers to risk management, and every business must prioritize its efforts, since it isn’t possible or practical to secure everything absolutely, and still function successfully. That’s risk management’s existential value. It’s remarkable to note that so many of the “discovered” special cases of risk or security would be reasonably well addressed by thoughtful and rigorous application of the foundational “basics” of risk management. This extends to cyber risk too.
Like so many other disciplines, those core components represent a baseline, not an ultimate state. More can and often must be done where the level of risk, the strength or severity of a threat, or the value of an asset may dictate. That is the realm of discretion, decision making, and informed management. There can be a tendency in today’s media to present excitement and promote some amount of immediate attention over new and sometimes pervasive threats. It’s good for selling content and sustaining readership, which is, after all, a key part of the media business. Still, it’s important to put these reports into the perspective of each businesses’ situation and operating needs.
There will always be new threat actors and new attack vectors, as well as the discovery of new or latent vulnerabilities. Risk management, and the application of supporting risk tools, like GRC software, will continue to evolve and develop features, methods, and practices to help companies meet these challenges.
[1] ZDNet, May 2020; https://www.zdnet.com/article/out-of-date-insecure-open-source-software-is-everywhere/
About the Author:
Simon Goldstein is an accomplished senior executive blending both technology and business expertise to formulate, impact, and achieve corporate strategies. A retired senior manager of Accenture’s IT Security and Risk Management practice, he has achieved results through the creation of customer value, business growth, and collaboration. An experienced change agent with primary experience in financial, technology, and retail industries, he’s led efforts to achieve ISO2700x certification and HIPAA compliance, as well as held credentials of CRISC, CISM, CISA.
