Victim notifications are exactly what they sound like—a notification that you have fallen victim to something. In the ever-changing world of cybersecurity, victim notifications happen more frequently as better detections and collaborations in the security industry lead to vulnerabilities either privately being disclosed to a product company or publicly being highlighted for the community.
Victim notifications can happen in several ways, but the following two methods are the most common:
Security product companies have used victim notifications to provide some additional top coverage for their customers as new threats emerge. As law enforcement throughout the world combines forces to take on some of the most prolific ransomware actors, their work and collaboration will likely result in new victim notifications for related incidents that were interrupted as a result.
Being notified of an attack can be a very confusing time if the organization is not familiar with the process. Typical questions arise, including:
Delivering victim notifications is something of an art form. There are no real rules or standards around how to disclose, but over the years some organizations have begun to standardize the process a bit more.
Some organizations will push the victim notification out through the product company’s sales representative. If a product company has a Managed Detection and Response (MDR) service, a representative from that team could be tasked with reaching out with some additional steps to help mitigate.
The delivery method and contents of the victim notification can help the organization ascertain if the notification is valid or not. If the notification is coming through proper channels from a valid email address, it should be taken seriously. (In fact, this is oftentimes a tabletop exercise played out during strategic security planning activities.)
Common ways to verify if a notification is legitimate include:
Whenever receiving a non-solicited email, phishing should always be at the forefront of your mind, especially as a global security incident is underway. This is especially true if there is no dedicated email address for the information security team. However, a knowledgeable person working to disclose a victim notification should provide at least the following information to demonstrate credibility:
Once the victim notification has been delivered, it's up to the victim organization to verify whether a potential incident impacted the organization—and if so, to what capacity. This can also cause some friction as the team determines what’s needed for an investigation.
Most importantly, does the organization know the proper timing to make these decisions? As the media spotlight has fallen on ransomware actors that operate in a ransomware-as-a-service or other various “affiliate” models, this is becoming increasingly important.
That’s because threat actors have varying levels of sophistication and speed. These speeds can range from two hours from initial compromise to weeks before the threat actor decides to deploy ransomware. These timelines depend heavily on the threat actor performing the attack and the security posture of the environment.
When discussing the victim notification with the organization that performed the disclosure, a key detail to understand is: “What is the typical end goal of the threat actor?” Sometimes these conversations will give information highlighting potential nation-state sponsors, commonly referred to as Advanced Persistent Threat (APT) groups.
Others may result in the notification of financially motivated groups like FIN7 or one of the many ransomware affiliate groups. Responding to these actors may require a different timeline based on the threat model of the victim.
Understanding the motivation behind the potential incident can help a security team understand the proper course of action to take when preparing to contain and eradicate a threat actor from the environment. Typically speaking, the threat of ransomware will spark the need for a more expedited containment and eradication effort than most other incidents.
The best way to prepare for anything—especially including ransomware incident response—is to practice. Build in quarterly, or as routinely as your team can accommodate, hands-on workshops that simulate the actual processes of handling a victim notification scenario. This should include, but not be limited to, working with your incident response team (in-house or third party) to understand the realistic time frames for requests.
Some typical areas that are hurdles for incident responders include:
Responding to victim notifications can be a daunting task, but it’s a fact of life in the current age. Victim notifications are considered “external notifications,” which means that the clock has already been ticking for some time.
As with any incident, it's important to understand the time frame in which the incident needs to be dealt with versus the time frame in which your organization can feasibly respond.
Adding this tabletop session in preparation for receiving a notification will help to narrow down the delta between the expected time frame for incident handling and the current operating capacity of your team.
This kind of preparation, coupled with practicing other topics related to responding to an event like a threat actor keen on deploying ransomware within your environment, will enable your team to be more prepared than the bad guys.