Increasing response speed for critical security threats
Risk Ledger's mission is to improve the security of the global supply chain, reducing the number and impact of attacks experienced through the supply chain by companies and consumers alike.
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.
We noticed that clients and suppliers struggled to respond effectively when a new, urgent threat was discovered.
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.
Turning the need into a 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.
The Minimum Viable Product (MVP)
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?
- Each client asked slightly different questions, but all were effectively asking for the same information.
- Some clients had an existing process to gather information from their supply chain: sending a list of questions to their most critical suppliers over email. This had multiple issues, but was the best solution they had.
- Clients struggled to keep track of and act on supplier responses.
- Suppliers responded in a timely manner, with some clients getting over 75% response rate.
Speaking to our users
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:
- Trust is incredibly important for a supplier to share information during an ongoing incident.
- There is a need to simplify the communication process between clients & suppliers in response to emerging threats
- Users are concerned about nth party suppliers, but feel there is not much they can impose or influence in this area.
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.
Using Risk Ledger to respond to Emerging Threats
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.
How do we define an emerging threat?
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 six 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.
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.
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.
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)?
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?
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.
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?
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:
Crowdsourced Threat Intelligence
The beauty of the Risk Ledger network lies in the wealth of knowledge & experience shared by our users. Currently, there are over 9000 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.