Partner Article

Rebuilding and securing supply chains

The pandemic has revealed just how vulnerable our supply chains can be, with many operations grinding to a halt and just as big a wake-up call came in the form of the SolarWinds attack at the end 2020 and the Log4j vulnerability a year later. The latter continues to persist in many third-party systems to this day. All these issues called into question the resilience of the supply chain and what can be done to build it back stronger.

One means of doing this is to build back with digital supply chains that use Application Programming Interfaces (APIs). These can be rapidly deployed and help to provide ease of integration between systems, enabling data to be quickly and easily accessed. APIs are the middlemen but can also help by acting on the data they receive, effectively creating a real-time chain of information that can be used to determine where the demand is and to monitor everything from inventory to shipping to purchase order status and a seamless form of communication between suppliers.

However, while its widely accepted that this form of digital supply chain can make the business more efficient, automating data sharing and enabling it to react to opportunities or risks, the management of the APIs themselves is often overlooked. These APIs can then turn into the weak points within the supply chain, exposing systems to attack. And given that threat actors are now routinely turning their sights on the supply chain that’s bad news. In fact Gartner predicts that 45% of organisations worldwide will have experienced attacks on their software supply chains by 2025 (a three-fold increase from 2021).

Do’s and don’ts

There are, therefore, some core things to consider when deploying APIs. It’s important to really nail down the implementation and to develop APIs that deliver only the necessary data, no more no less. This then prevents the exposure of unnecessary data to supply chains that could end up in “the wrong hands”. Implementations should also ensure that non-production supply chain APIs (i.e. those used for testing and integration purposes) are deployed in private locations and are not open to a malicious actor to find for reconnaissance. If they do happen upon a non-production API, this can effectively provide them with the blueprint to then attack the production version.

APIs should not be considered as operating outside the realms of normal practice - they require the same level of governance, compliance, and security as any other supply chain service. Supply chains are often put in an “allow all” security group, which then goes unmonitored. Companies should consider employing a weighting, or confidence system whereby a supply chain starts out with a negative score which, if malicious, suspicious, or data exfiltration behaviour is detected, is then elevated. This will counterbalance the negative weighting, thus allowing an attack via a supply chain to not go unnoticed.

When API keys are shared with suppliers, this should be done securely and the concept of least privilege applied, so that the supplier is confined to resources relevant to them and does not have access to the “keys to the kingdom”. Here it’s also worth pointing out the danger of “double API Keys” being in the supply chain. This occurs when attackers leave client API Keys in their attacks with the supply chain API key also present, doubling the exposure.

API definition and specifications should be shared securely with supply chains and not left open for anyone to access, as this again acts as a blueprint to an attacker. Adherence to these specifications should be monitored in run time monitoring in order that compliance and governance standards are adhered to. Any behaviour outside of the definitions should be flagged immediately and ideally prevented, not just alerted to the security team. Rather than simply detecting and generating a “sea of events” for analysis, businesses should be putting in place guard rails that are frictionless to developers, but which can prevent malicious, suspicious and data exfiltration behaviour.

Third-party threats

Consider also that third-party APIs are often brought into the organisation without security teams being aware of them. It could be that the partner team or business group managing the third-party relationship believes they are dealing with a secure API already. Or perhaps the API is disclosed to the security team but has subtle flaws or a vulnerability that can be exploited. Even perfectly coded and implemented third-party APIs can be targeted by threat actors if they feel the time spent studying it is worth the data asset it connects to or the service it fulfils.

Furthermore, as certain third-party ecosystems grow, by their nature they become a valuable single point in the digital supply chain where an attacker could use a trusted API to target many victims.

In the case of one financial services organisation we assisted, the ecosystem APIs hosted by that organisation were targeted to simultaneously attack multiple partners using the APIs. The coordinated credential stuffing campaign that ensued saw the attackers cycle their malicious traffic through the partner API which provided money management features including cross-account visibility, retirement planning, and net-worth tracking.

The attackers were aware of this one-to-many connection in the institutions’ supply chain and they knew that these API calls likely came from allowing trusted applications, originating from the attackers’ ultimate target – the banks themselves. Therefore, instead of attacking the bank directly, the attackers targeted the trusted API ecosystem and by proxy, the partner banks. Thankfully the attack was mitigated by picking up on identifiable behaviours with over 50 million requests blocked within a single week.

As was illustrated in the case of the SolarWinds attack, APIs can be used as a malware delivery mechanism in supply chain attacks. A more recent example can be seen in the LoNg4J variant of Log4j, where susceptible servers were found through API-connected (and trusted) third-party applications such as logging and SIEM solutions.

The persistence of Log4j

A survey during 2022 of client systems found unpatched servers deep within digital supply chains which saw alerts appear some 15 hours after the initial patching had been carried out. The inference was clear – while the clients had patched their systems, their partners had not, which meant they would see a clear result when running tests when in fact they were still at risk of compromise via their partner’s systems.

The vast library of internal and third-party servers that organisations have deployed means the vulnerability will be with us for years to come. In the last six months of 2022, over 4,000 instances of Log4j were detected in the wild, revealing that businesses must remain vigilant, regardless of how successful their patching efforts appear to be.

Looking to the future, we can expect faster time to delivery of new functions and features thanks to APIs and easier consumption and therefore more prolific adoption across supply chains. But as API adoption and dependency grows, so too will the complexity of managing and securing them, so businesses must ensure they tightly control their deployments.

API rollout can quickly escalate and see businesses lose track of how many APIs are out there and what information they carry. For this reason, it’s imperative to have an API security strategy that includes the three elements of runtime discovery, threat detection and defence. APIs are the new foundation of our digital supply chains and as such warrant protection.

This was posted in Bdaily's Members' News section by Cequence Security .