by Phil Martin
Figure 157: Software Supply Chain Risk Management Goals
Whether an outsourcing or managed services approach is used to leverage external parties, the primary benefits are the same. They will deliver cost savings and tax incentives for the acquirer, as outsourced services can now be reported as operating expenses instead of capital expenditures. Offloading ‘fringe’ needs onto another entity can allow a company to focus on
their core expertise and provides much-needed access to experts in the service area when needed, who can remain objective in their input. Because managed service providers will usually run multi-tenant SaaS applications, the use of such global software forces a company to align with common standards instead of developing proprietary, one-off solutions in-house.
Chapter 47: Threats to Supply Chain Software
While outsourcing software can result in significant cost savings, tons of risk now enters the company’s sphere due to three primary issues:
1) The company is now dependent on an external party to deliver on their promises.
2) An external company is now ‘inside’ of the company’s protected infrastructure and/or processes.
3) The company must live within the constraints of how flexible the software is.
Regarding the last point on flexibility, there exists a rule of thumb in the development world: ‘As flexibility increases, performance decreases.’ While that rule is a conversation for another book, a corollary of that rule is: ‘As reuse increases, flexibility decreases.’ In other words, as the number of different consumers a product services increases, the less flexible the supplier can be when it comes to accommodating customization requests from one customer. As an example, let’s say your company uses an online payroll service, and HR wants the ability to run a report that does not exist. Unless you happen to be the supplier’s biggest customer, your request will almost certainly be denied. If the supplier were to implement the requested report, then they would have to roll it out to all of their customers since it is a single application with multiple tenants. This would require a ton of testing and preparation and will not make economic sense to the supplier.
Additionally, when handing our data over to be hosted by someone else, we increase the risk that our intellectual property, or IP, would now be
accessible by the supplier. Worse, what if one of their other tenants was one of our own competitors, and due to the lack of security mechanisms that competitor was able to view our data? That could be disastrous.
If security requirements are not stated up-front in a contract with the supplier, they more than likely will not ever be implemented. Even if security is included in the original requirements, and the supplier agrees to meet the requirements, the company seldom validates that sufficient security controls are present. Too often people will focus on ensuring that features and performance are met with little regard to how effective the security controls are in the target environment. The Reagan-ism ‘Trust, but verify’ comes into play here. We trust the supplier will properly implement security, but at some point we must verify that it actually works correctly.
Now that we have covered the issues inherent in any supply chain, let’s break apart the ‘chain’ and see what components are inside. The components can be of three different types as shown in Figure 159 – products, processes and people. A product represents the software or service, along with any data required by the software or service. A process is an activity around the product. For example, the requirements analysis is a process, as are risk management, configuration management and final disposition when the product is retired. Product flows and software development activities are also considered processes. The people component is pretty much self-explanatory – it refers to any human involved with the product or a process. It is more useful to discuss roles instead of individuals, such as the quality assurance, project manager, prime contractor or requirements owner roles. Figure 158 illustrates the various paths that software can take in a supply chain.
Figure 158: Potential Software Supply Chain Paths
Figure 159: Supply Chain Components
When a supply chain is attacked, it is called – wait for it – a supply chain attack. In general, we can group supply chain threats into three categories – product, processes, and people as shown in Figure 160. This might sound familiar, as the use of the three P’s is an-oft used way to break down a complex situation into something that can be understood. In fact, we just used the same approach when looking at the entire supply chain. So, don’t get confused when you run into it again here. In this case, we are breaking down threats into the three P’s.
Figure 160: Supply Chain Threats
A product or data threat happens when an attacker tampers with the code to get around existing security controls. Such an attack will usually result in one of two unwanted effects – either the modification of the software, or the injection of additional files or logic. Of the two, injection of malicious code is the greatest danger and occurs during or after the development and testing phase. This attack will result in information disclosure, alteration, corruption or destruction of data. Although not a result of modification or injection, reverse engineering falls under this category and can result in piracy or theft of intellectual property.
Process and flow threats occur when an attacker is able to bypass legitimate workflows and instead substitute his own. This is caused by insecure code transfer (remember software provenance points?) that do not maintain a chain of custody. This can often cause the software chain to violate
export control requirements. This type of threat can also be caused by improper software configuration that allow undocumented modifications.
People threats can come from many sources. Beyond accidental insiders, a malicious threat agent might intentionally place an individual inside of a company to carry out the agent’s agenda. This type of a people threat is called an insider threat or a pseudo-insider threat. Employees or an attacker can carry out social engineering attacks with the intent to commit fraud or perjury. Foreign ownership and control of influence, of FOCI, is a concern that recognizes attacks resulting from an affinity to a nation or state. For example, a nation-state sponsored hacker might attack a power grid, or a lone individual could launch an attack on a country based on his hatred for that nation.
Chapter 48: Software Supply Chain Risk Management (SCRM)
Just as a single broken link in a chain can render the entire chain useless, a single weakness in the software supply chain can completely negate all other protection mechanisms. This is even more true when the supply chain is global in scope, encompassing facilities and teams in multiple countries. When dealing with a supply chain, managing risk is called supply chain risk management, which makes sense. We usually just use the acronym of SCRM when referring to it, though.
The sources of weaknesses – or ‘threats’ depending on how you want to view it – can come from a myriad of sources:
Incomplete validation of suppliers.
Security requirements that do not appear in contracts.
Unintentional design flaws and code bugs that create an opportunity for exploit.
Intentional injection of malicious code after the development process has ended.
Allowing code to be disclosed due to weak access controls.
Not following a code publishing process that guarantees authenticity.
Improper configuration during installation and deployment.
Weak vulnerability and patch management processes.
The failure to properly validate security controls that the supplier has promised.
As you can see, risk is not centered on our own development processes – when outsourcing or using managed services we must take on the risk generated by the external parties as well. Software supply chain risk management follows a series of rigorous steps, listed in Figure 161:
1) Identify risks
2) Validate controls
3) Acquire the software
>
4) Continuously assess risk
5) Dispose of the software
Figure 161: SCRM Steps
So, if the supply chain is so risky, how do we protect it? It turns out that there are six primary controls we can leverage to assure security, shown in Figure 162.
We have already discussed least privilege, but when applied to SCM it means that the people who have access to code and/or data are given only the minimum set of rights needed to do their job and only for the minimum amount of time.
Separation of duties is also a well-worn topic, but when implemented with SCM, SoD ensures that tampering, unilateral control, collusion and fraud are highly unlikely.
SCM security controls should never be dependent on a specific geographical or logical location – the control should work regardless of where the software happens to be in the world. When controls provide location agnostic protection, they are often referred to as persistent protection.
It is crucial to not only provide for, but to insist on, code inspection. This allows us to detect and identify malicious logic during the development cycle.
All code and data should be protected with tamper resistance, and evidence of this should be readily apparent. Hashing and digital certificates providing proof of authenticity must be used to ensure no one can alter the code and data.
Finally, a chain of custody must be kept when transferring products from one supplier to another at provenance points. Any transfer must be fully documented, authorized, controlled, transparent and verifiable. A chain of custody proves this process is carried out properly.
While all of this sounds great, we must remember a single, undeniable truth: while outsourcing requires both the supplier and acquirer to share in implementing proper security, when a security breach happens – and it will – the acquirer bears full responsibility. The lesson learned here is that
you can never trust a supplier to hold up their end of the bargain, unless you put the requirements in the contract and verify yourself that they are implementing and following security controls. Here are a few questions that should be asked of each supplier:
Do they have a security development lifecycle, or is it ad-hoc?
Can they assure that software or services are authentic and tamper-proof?
Is the facility where the supplier develops code secure?
Is data secure when being stored, processed and transmitted between suppliers?
Is the communications channel between suppliers secure?
Figure 162: Protecting the Supply Chain
Chapter 49: Acquisition Lifecycle
Aside from the various components of product, process and people, the supply chain can be broken up into eight different phases – planning, contracting, development and testing, acceptance, delivery, deployment, operations and monitoring, and retirement. Figure 163 illustrates the sequence of the phases, while
Acquisition Lifecycle Phase
Supply Chain Risk Management (SCRM) Activity
Planning
Perform an initial risk assessment to determine requirements (protection needs elicitation)
Develop acquisition strategy and formulate plan with evaluation criteria
Contracting
Include SCRM as part of the acquisition advertisement (RFP, RFQ, etc.)
Develop contractual and technical control requirements
Perform Supplier Risk Assessment (supplier sourcing)
Evaluate supplier responses
Establish intellectual properties (IP) ownership and responsibilities
Negotiate and award contract
Development & Testing
Evaluate conformance to assurance requirements
Conduct code reviews
Ensure security of code repositories
Ensure security of build tools and environment
Conduct security testing
Acceptance
Validate anti-tampering resistance and controls
Verify authenticity (code signing) & anti-counterfeiting controls
Verify supplier claims
Delivery
Maintain chain of custody
Secure transfer
Enforce code escrow (if required)
Comply with export control & foreign trade data regulations
Deployment
Configure the software securely
Implement perimeter (network) defense controls
Validate system of systems (SoS) security
Operations & Monitoring
Check runtime integrity assurance controls
Patch and upgrade
Implement termination access controls
Check custom code extensions
Continuously monitor software/supplier
Manage security incidents
Retirement
Decommission (delete) or replace software
Dispose data to avoid data remanence
Figure 164 adds additional information. Let’s briefly describe each and then visit the phases in greater detail.
Planning is where we conduct an initial risk assessment to document the needed functionality, followed by the development of an acquisition strategy. During this time evaluation criteria should be decided on and documented, and should ideally include four categories – organization, people, processes and technology.
The contracting phase is where RFPs are sent out to potential suppliers, negotiations are carried out, and ends with the final supplier selection.
The third phase in the supply chain acquisition lifecycle is development and testing. Here is where we implement any required customizations and coding, including security controls.
Figure 163: Supply Chain Phases
Next, we carry out the acceptance phase in which we define the acceptance criteria, issue the purchase order, carry out testing by third-parties, and sign the contract.
The delivery phase covers the secure delivery of the software or service. Here, ‘secure’ means that we can verify that the final delivery comes from the real supplier and has not been tampered with during transit. If code escrow is required, this is the time to establish the capability and to ensure compliance with any applicable export regulations.
The sixth phase is where deployment happens as the software is installed with least privilege and secure defaults. The software as it lives in the target environment is assessed end-to-end to assure a secure computing stance.
Operations and monitoring are then carried out to assure proper change management, patching management and continuous monitoring. Incident and problem management are included in this step as well.
Acquisition Lifecycle Phase
Supply Chain Risk Management (SCRM) Activity
Planning
Perform an initial risk assessment to determine requirements (protection needs elicitation)
Develop acquisition strategy and formulate plan with evaluation criteria
Contracting
Include SCRM as part of the acquisition advertisement (RFP, RFQ, etc.)
Develop contractual and technical control requirements
Perform Supplier Risk Assessment (supplier sourcing)
Evaluate supplier responses
Establish intellectual properties (IP) ownership and responsibilities
Negotiate and award contract
Development & Testing
Evaluate conformance to assurance requirements
Conduct code reviews
Ensure security of code repositories
Ensure security of build tools and environment
Conduct security testing
Acceptance
Validate anti-tampering resistance and controls
Verify authenticity (code signing) & anti-counterfeiting controls
Verify supplier claims
Delivery
Maintain chain of custody
Secure transfer
Enforce code escrow (if required)
Comply with export control & foreign trade data
regulations
Deployment
Configure the software securely
Implement perimeter (network) defense controls
Validate system of systems (SoS) security
Operations & Monitoring
Check runtime integrity assurance controls
Patch and upgrade
Implement termination access controls
Check custom code extensions
Continuously monitor software/supplier
Manage security incidents
