Product Update
Risk Ledger API
Fundamentally, this means helping organisations throughout the world to stop bad things from happening in cyberspace and reducing the negative impact when they do happen.
So far, Risk Ledger and other supply chain security solutions have been focused on preventing and preparing for things that may or may not happen: understanding the risk of future events.
How likely is it that this supplier will put my data, my reputation, my business at risk, given its security maturity? How can I mitigate or reduce this risk?
This is the ongoing third party risk management that organisations perform as part of their risk governance or supplier assurance efforts. This was not easy to do - traditional approaches were slow, cumbersome and ineffective. Risk Ledger solved this problem for both clients and suppliers by connecting organisations through a network model, allowing them to share information and collaborate on security improvements.
This is important work, but it is only part of the picture.
There was a disconnect between operational response teams and teams managing supply chain risk. They very rarely worked effectively together during an incident, and thus operational response teams didn’t have the data they needed on supply chain exposure.
A huge part of improving security is being able to respond quickly and efficiently. This is well understood, but is rarely successfully applied to the supply chain. We’ve made significant progress in continuous risk management, but people are not equipped to deal with the bad stuff as and when it happens.
During an evolving threat scenario, the security team need to be able to collect data to make an informed decision on the risk each supplier poses to them, advise the business on the risk, and work alongside their suppliers to remediate or mitigate any risk - whether that’s supporting the supplier to speed up their patching, or quarantining supplier connections until it can be confirmed there is no compromise.
Suppliers may be inundated with messages from their clients, often asking the same questions: Are you affected? Is my data compromised? How are you responding? How important the client is to the supplier usually dictates the timeliness and depth of the response. Due to the time sensitivity and urgent nature, the supplier is having to juggle their own incident response, understanding the threat and their exposure, whilst fielding a multitude of well-intended questions from their clients.
The solution some organisations had landed on - sending questions manually over email and often waiting weeks for a response - did not feel adequate against agile, opportunistic and often well-resourced attackers. We recognised that the communication network we’d built across organisations presented a huge opportunity to build a better solution.
Once you’ve defined your user and problem space, the next step is to deliver a solution that truly meets their need. This requires a huge amount of listening, understanding and iteration. It is a continual journey through user experience, digging into the fundamental pain points and opportunities.
Through Risk Ledger, clients and suppliers are continually connected, much like a LinkedIn connection. Among other things, this enables them to send messages to each other - usually to ask clarification on controls, request remediation or share best practise. When the critical Log4j vulnerability was discovered in December 2021, some of our clients asked if they could send a message to all connected suppliers asking about their response. Sending a bulk message to all connections was not a capability clients had within the product, but our tech team quickly made it work. Through this, clients could quickly gather data about how their supply chain was affected by Log4j. We did the same thing when Russia declared war on Ukraine. What did we learn?
To really understand the need, we needed to speak to our users. We did this in two ways: user discussion groups and 1-1 discovery calls. During these conversations, we were able to dig into what users currently did when a new threat was discovered, what their challenges were, and what they would like to be able to do in an ideal world.
The discussion groups also allow users to learn from each other - a simple conversation between security professionals sharing their experiences can have a huge amount of value.
From this, we learnt:
With the discovery underway, then comes design & build: ideation workshops, user feedback and validation, opportunity prioritisation, proposal writing, visual design, usability testing, technical design, build and iteration, until we have the first version of the Emerging Threats feature.
When a new emerging threat is identified within the industry, suppliers will be notified and asked to provide information about their status relating to the threat. This will be structured around a status and a few simple questions.
Clients can then view and analyse their exposure through their supply chain.
When the next Log4j hits, Risk Ledger clients can now get an immediate snapshot of how their supply chain is affected.
An emerging threat is something new, often not yet fully understood, that impacts the cyber security of a large number of organisations. For example; a new critical vulnerability (Log4j), a change in geopolitical situation (war), or an ongoing cyber attack (Solarwinds). When a new emerging threat is discovered, there is a sense of urgency and time sensitivity.
Threat intelligence is a noisy space. Each organisation needs to be constantly analysing which threats are relevant to them and worthy of attention, so as not to be overwhelmed by sheer volume. In the context of the supply chain, we are not looking at threats relevant to any one organisation, but ALL organisations. So how do we determine which threats warrant that attention?
There are seven separate considerations we go through before publishing an emerging threat to the Risk Ledger network. The intention is to provide a consistent framework so all users know what to expect, but we will evolve these considerations over time as we learn and iterate.
1. Public domain
We may become aware of issues which are not in the public domain - embargoed or otherwise legally restricted. We will need to ensure we are working within the law when we publish an emerging threat.
2. Ubiquity
Is the threat contained to a small geography, environment, or a particular technology? We will only publish threats which could affect a large proportion of organisations.
3. Severity
A combination of exploitability and potential impact determines the level of attention and action needed. We will only publish threats where we deem the potential severity is high. If the threat is related to a new vulnerability, the CVSS score will be taken into account.
4. Maturity
Is there a robust consensus about the detail of the threat? Can we trust the information available to us about the threat (even if proposed mitigations are still under development)?
5. Publicity
Are we comfortable that the level of publicity is justified and not unduly affecting our decision? Are large clients or lobbyists influencing the conversation. Would an objective analysis of the threat align with the level of media attention?
6. Benefit
By publishing the emerging threat on the Risk Ledger network, does this better enable both clients and suppliers to respond effectively? Are we likely to have a positive impact on security?
7. Integrity & credibility
Is there sufficient confidence in the publicly available information? Are there credible sources we can reference to demonstrate integrity of the information?
Once an emerging threat is published, the picture of which suppliers are affected, how they are connected, and how they are progressing through remediation efforts continues to build on Risk Ledger. This is what it looks like:
The beauty of the Risk Ledger network lies in the wealth of knowledge & experience shared by our users. Currently, there are over 18,000 users on the Risk Ledger network from security teams across the world. Between us, we can stay ahead of attackers and work together to defend as one.
Vendor management can be a headache, especially during an emerging threat; but it doesn’t have to be. If you’re looking to modernise your third-party management process speak to a member of the team.
Sign up to our monthly newsletter to receive exclusive research and analyses by our experts, the latest case studies from our clients as well as guides, explainers and more to turn your supply chain risk management programme into a resounding success story.
