Supply chain risks have shown that they can trigger delays in shipping and production worldwide — but software supply chain risks can poison a business overnight.
Core business operations have been affected in recent incidents like the sophisticated SolarWinds campaign or vulnerabilities in open source libraries that are commonly used but hidden under layers of dependencies, like Log4j. Gartner listed digital supply chain risks as one of the top 7 security and risk management trends for the year, predicting that almost half of organizations worldwide will experience software supply chain attacks by 2025.
The risks are rising, technical controls alone are not enough protection, and organizations face several challenges for risk management.
Organizations might fail to manage software supply chain risks when they:
- Struggle to negotiate favorable terms as they buy software from their suppliers
- Procure or deploy software without inputs from cybersecurity teams, for fear of being blocked or delayed
- Procure software from a third party that has not developed and does not own the source code, or has dependencies on parties farther down the line
- Have a business culture that chooses to “accept the risks” until there is an incident
- Have not established a cross-functional enterprise approach to managing the risk
Risks can arise from sophisticated attacks made by nation-states, or from comparatively simple attacks by ransom seekers. In either case, organizations need software supply chain risk management in place.
Criticality and impact analysis
To manage software supply chain risks, organizations should start with an understanding of what they are entrusting to software suppliers. Perform a business criticality and impact analysis for each third-party application.
As you complete the matrix, consider questions like:
- Can we continue as usual if we suddenly lost access to this software? If not, what would be the impact of that loss?
- How risky is that data being handled by that software? What would be the consequence of that data one day appearing on the open internet?
During this phase, organizations should also evaluate whether the new application will expand the organization’s attack surface. This can give attackers opportunities to pivot internally to other critical assets, using API calls for example.
Risk tolerance estimation
After organizations plot each third-party application on a criticality and impact matrix, they should consider the amount of risk they can tolerate in each matrix band. For instance: What would make you feel confident in your supplier’s ability to resist attacks against your riskiest data or most critical apps?
Quantify the impact of a potential disruption, and the likelihood of disruption if a control point should fail, to help define the security requirements you expect to see implemented in the software that you are considering. For example, the sensitivity of the data involved might evoke requirements for data encryption and key management.
When a software supplier confirms that it can satisfy your baseline security requirements, that may feel like a win for the compliance team — however, the software might still use vulnerable open-source libraries, and it might not address critical security risks. How can an eager software supplier provide you with an acceptable level of comfort?
For some organizations, that acceptable level of comfort would require a full-scale adversarial test using the most sophisticated intrusion techniques. Other organizations might want a thorough understanding of the supplier’s internal security controls, like asking the supplier to demonstrate adherence to leading secure software development lifecycle and DevSecOps practices, or show that controls have been validated by a reputable auditor. You might choose to perform security testing on your own.
Security testing
Most cybersecurity leaders are faced with the reality of having to balance security against resource availability and responsiveness to the business. So, it may not be practical to engage NSA-certified testers for each of the most critical applications. Here are some of the assurance activities that can provide appropriate confidence — and level of comfort — in the security posture of a third-party software solution:
Moment-on-time reviews are insufficient in today’s world of weekly, if not daily, code releases. So, how frequently should you conduct testing? Your approach can range from an annual self-attestation or recertification to monthly vulnerability find-and-fix reports from your software suppliers. You could even enroll in a continuous manual penetration testing program where your third-party applications are tested without prior notice to the software supplier.
Secure software acquisition policy
Your software supply chain risk analysis, security requirements, and approach to assurance requirements will help define your internal policy and decision-making process for software acquisition.
This secure software acquisition policy should cover how your organization thinks about its data and business operations, capturing your criticality impact analysis and the levels of assurance appropriate for each criticality and impact band. It should also include the appropriate terms of acquisition, or the requirements imposed on the organization’s software suppliers.
“The secure software acquisition policy is an expression of consensus about the organization’s risk tolerance.”
This policy should be detailed enough to direct contract negotiations with software vendors, ensuring the right security requirements are included and that terms flow down to nth-party providers of code for critical and sensitive applications. “The secure software acquisition policy is an expression of consensus about the organization’s risk tolerance,” noted Grant Thornton Cybersecurity and Privacy Advisory Services Managing Director Maxim Kovalsky.
The point where you negotiate terms with a vendor is not the time to internally ask, “Really, how committed are we to our policy?” That’s why senior business leaders should be prepared to accept that a software supplier’s inability to follow this policy may require walking away from an otherwise desirable business relationship.
Roles and responsibilities
Your secure software acquisition policy needs to identify the stakeholders involved in the software acquisition process and their roles in this process. This helps to ensure the appropriate support for your policy, and clearly defines important roles and responsibilities across the organization, such as:
- Software acquisition and testing requirements, in process flows with distinct decision trees based on pre-set criteria and technology platforms or solution categories.
- Swim lanes or defined activities across all stakeholders, including:
- Business and technology owners
- Back-office support teams, like sourcing, procurement and supply chain
- Second line of defense (LOD) subject matter expert groups, like compliance, technology, business continuity and security
It is important to ensure that each area understands its responsibilities for enforcing the policy. Outside of established Secure SDLC standards and company policies, management oversight for control points in the development and change processes can quickly break down when you introduce third parties and, in turn, their own suppliers. Control execution might pass down the supply chain to vendors, but your organization remains responsible to monitor control adherence.
- Business owners (application owners) must:
- Articulate their risk tolerance
- Identify critical nth parties throughout the software supply chain
- Perform routine ongoing monitoring of service delivery
- Track KPIs and KRIs
- Act as the key reviewer and approver for technology platform acquisitions and changes
- Perform user acceptance testing (UAT)
- Procurement must:
- Ensure that the requirements articulated in the secure software acquisition policy are reflected in each software acquisition and development contract
- Provide governance and oversight of the onboarding and contracting processes
- Legal must:
- Act as the decision maker on approved contract terms and conditions, SLA’s and vendor responsibilities, including control points and fourth-party oversight
- Define in-scope legal requirements and terms/jurisdictions to which the agreement will be subject
- Privacy must:
- Establish minimum standards and requirements for data-privacy-related processing activities and inventory
- Perform Subject Matter Expert consultation and data types/classification, privacy requirements and processing activities spanning outsourced technologies and third party providers
- IT Operations must:
- Establish technical requirements for system architecture, hosting/access mechanisms and operational resilience
- Perform Subject Matter Expert consultation over the contracting process and software acquisition due diligence
- Security must:
- Establish minimum standards and requirements for security, development, and testing standards
- Perform Subject Matter Expert consultation over the contracting process and software acquisition due diligence
- Act as a key reviewer and control owner throughout the acquisition, development, and implementation of technology solution
- Risk and Compliance must:
- Serve a control or monitoring function (such as second line of defense oversight) to ensure compliance with secure software acquisition policy
- Consult risk, IT and third-party-management experts as needed to monitor compliance with secure software acquisition policy and perform centralized, repeatable, high-volume and lower-risk control functions on behalf of the business
Digital supply chain risk management requires unity
To assess and manage digital supply chain risks, organizations need:
- Criticality and impact analysis which provides input for the
- Risk tolerance estimation that forms the baseline for
- Security testing that is detailed and required in a
- Secure software acquisition policy that outlines controls with the
- Roles and responsibilities for risk management
With all of this in place, organizations will require unity around the importance of software supply chain risk management.
All of the individuals identified in your policy must understand their roles and the importance of enforcing the policy. Any exception to the policy is a fundamental flaw, as it brings into question the hard-earned consensus about the organization’s risk tolerance. An exception can also introduce questions like: How frequent are exceptions allowed, and who is assuming these risks across the organization?
While many organizations treat policy exceptions and risk acceptances as synonyms, we argue that risk acceptance naturally occurs as you determine your requirements and level of assurance appropriate for the business use cases of software being procured. That is, the organization may accept that a less critical application will be subject to less stringent security requirements, and that visibility into how those requirements are enforced may be limited. Exceptions then should be treated as a deferral of specific assessment activities and controls until a date in the very near future.
Software supply chain risks are only growing in their importance, as shown by recent attacks and legislation like the White House Executive Order 14028: Improving the Nation’s Cybersecurity. Increasingly, these attacks pose a fundamental business risk to organizations. That’s why it is essential to intentionally form and enforce an organizational policy that helps to manage software supply chain risks.
More advisory whitepapers
No Results Found. Please search again using different keywords and/or filters.
Share with your network
Share