Bernalillo County, New Mexico, started off 2022 the victim of a ransomware attack. Not a lot is known about the attack at the time of this writing, but it has all of the hallmarks of a ransomware attack against a municipality:
But there is an interesting side note on the county’s status page:
Vendors for county systems have been notified of the ransomware and are working to solve the issue and restore the system functions.
Why would a ransomware victim proactively reach out to vendors to notify them of a ransomware attack? Believe it or not, this is becoming more commonplace–in fact, many vendors now require this kind of notification from their clients.
It is not uncommon for organizations to have multiple vendors connected to their networks. Some vendors, such as Managed Service Providers (MSPs), may require direct connections to manage parts of their client’s networks, but others may need connections into the network for administration and maintenance of specific servers or systems. These types of connections generally happen with specialized systems, like those used in healthcare and manufacturing.
Whatever the reason, ransomware groups will often take advantage of this interconnectedness to launch ransomware attacks. Attacks like the Kaseya ransomware attack have spawned copycat attacks by ransomware groups, looking to exploit vendor vulnerabilities to gain access to their clients.
However, that attack methodology can also work in reverse: a ransomware victim’s network can be used to target that victim’s vendors, creating a cascade of ransomware attacks.
To that end, many vendors are now requiring their clients to report ransomware attacks to them, and some vendors include language in their contracts that they will temporarily disable access to any of their clients experiencing a ransomware attack.
Often, this means that employees of a ransomware victim will not only not be able to access their local systems, but also any vendor-supported systems that have been temporarily disabled. This adds an additional level of disruption to everyone’s work, including those working from home, as often critical vendor services are suddenly unavailable.
Given this new reality, organizations have to include vendor response in their ransomware incident response plan. As always, now is the best time to do this, before a ransomware attack happens. There are a few steps every organization should take immediately:
This third point is increasingly important. I’ve witnessed a number of cases where a ransomware victim had vendors disrupt services because they got incomplete information from a victim’s help desk or IT team.
Additionally, sometimes the ransomware actor will notify vendors of their victims, to increase pressure to pay the ransom. You definitely don’t want your vendors to find out about a ransomware attack from the ransomware actors first.
Vendor communication is important, and internal communication to impacted teams is a critical component of that communication chain. Any internal communication should include an understanding to direct all external queries to the team authorized to share information about the attack.
Centralizing communication during a ransomware attack and making sure everyone in the organization understands who is responsible for communication helps ensure that incorrect information is not accidentally shared. No one, especially vendors, wants to create more disruption during a ransomware attack, but vendors have to protect themselves and their other clients. Effective communication with your vendors during an attack can help keep those critical services running while your organization is recovering from a ransomware attack.